bug#51038: 27.2; ELPA certificate not trusted on Windows

[Eli Zaretskii]

tags 51038 notabug
thanks

> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> Date: Sun, 24 Oct 2021 19:21:00 +0100
> Cc: john@rootabega.net, 51038@debbugs.gnu.org, emacs-hoffman@snkmail.com, 
>       Lars Ingebrigtsen <larsi@gnus.org>
> 
> (apologies for being pedantic here, just want tom make sure that any
> difference in opinion become clear)

I wasn't aware that we are having differences of opinions here.

> before going into the details of a workaround, my argument is that
> this is an issue with the precompiled binaries of the latest official
> Gnu Emacs release at the official ftp site. If a user or process
> installs today these binaries on their system, Emacs will not work to
> its full potential. Furthermore, the user will not be aware why the
> connection to the elpa archive fails nor of a potential work around. I
> consider this to be a major issue with the precompiled binaries
> prepared by the Gnu Emacs projects, that they don't work out of the
> box and likely to leave the user/system in a perplexed/volnurable
> state.

That is true, but users who download precompiled binaries are at the
mercy of whoever prepared the package from the get-go, so this danger
is not new, it is inherent to this way of installing Emacs.  People
who want to be completely in control should compile Emacs by
themselves.  We have instructions for that in nt/INSTALL.W64.

> May I point out that libgnu-2.6.12 ships in emacs-27.2-x86_64.zip
> under bin/libgnutls-30.dll, and thus the responsibility to the
> maintainer of the package to fix any shortfalls IMHO?

We don't have a maintainer at this time.  This was (and is) a
volunteer project, and the volunteer who produced that bundle stepped
down.  If you'd like to replace him, I'm sure this will be very
welcome.  Or maybe someone else will soon.

> Currently the
> official instructions to install the latest Gnu Emacs release from the
> precompiled binaries from the official ftp site, install a version of
> Emacs which is impaired, and wont work to its full potential out of
> the box for any user.  We need to either fix this so it works out of
> the box, provide official instructions how to work around it, or
> provide an official note that this is broken. Letting users being
> unaware and thus vulnerable to the current behaviour IMHO is
> suboptimal.

There's a problem with the "we" part here.  There's also a problem
with providing instructions, because the fine details depend on what
is already installed on the end-user's system.  It's hard to provide a
cookbook here.

> With regards to the suggested workaround

It isn't a workaround, it's THE solution.

> 1. I've downloaded and unpacked
> http://ftp.gnu.org/gnu/emacs/windows/emacs-27/emacs-27.2-x86_64.zip to
> a local directory.
> 2. Looking for the GnuTLS precompiled version for windows, I landed on
> this page: https://www.gnutls.org/download.html
> 2.1 There is a latest w64 version on gitlab link at
> https://gitlab.com/gnutls/gnutls/builds/artifacts/3.7.2/download?job=MinGW64.DLLs
> that redirects to a 404.

The correct place to update GnuTLS is from the MSYS2 project, which is
where all the optional DLLs in the binary bundle come from.  The URL
is in nt/INSTALL.W64; start by installing pacman, and then fetch the
latest mingw64 libgnutls DLLs.  (I myself don't use that, so
unfortunately I cannot give you more details, but perhaps someone else
here will.)

Alternatively, I believe you can tell the Emacs NSM, once, to trust
ELPA regardless of the certificate, and then it will work henceforth.
(This _is_ a workaround.)

In any case, this is not a bug in Emacs.