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

[Ioannis Kappas]

On Sun, Oct 24, 2021 at 7:50 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > 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.

Great, I think we came to an understanding

1. Issue is  not with Emacs.
2. Issue with the latest official precompiled binaries of Gnu Emacs
for MS-Windows, caused by the bundled GnuTLS library version.


> > 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 disagree with this that there is nothing to suggest that in the
the official download page @
https://www.gnu.org/software/emacs/download.html, under Nonfree
systems/Windows:

"""
Windows

GNU Emacs for Windows can be downloaded from a nearby GNU mirror; or
the main GNU FTP server.
Unzip the zip file preserving the directory structure, and run
bin\runemacs.exe. Alternatively, create a desktop shortcut to
bin\runemacs.exe, and start Emacs by double-clicking on that
shortcut's icon.

The Windows binaries are signed by Phillip Lord 8E64 B119 FE4B AC58
C767 D5EC E095 C1A6 3FB1 EAD2.
"""

If this is the official position, IMHO it should be clearly stated
somewhere obvious (unless I missed it). Otherwise people old or new to
emacs think these precompiled binaries are officially supported by the
project maintainers and should work out of the box.

> > 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.

I could possibly assist if needs be. I assume this is based on
trusting the person creating the package rather than having an
automated build process in place.

> > 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.

My experience with the precompiled binaries zip file is well self
contained and does not depend on anything outside of it, other than
the windows kernel.

> > With regards to the suggested workaround
>
> It isn't a workaround, it's THE solution.

OK, there is a slight difference of opinion here. The solution for me
is to update the precompiled binaries with a recent GnuTLS version on
the official download site.  Having the user to install MSYS2 and
locate the dll (or download the latest version from the GnuTLS CI) as
to overwrite the a single dll in the official precompiled binary,
sounds like a work around to me.

> > 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.)

Yeah, I've tested this to work too. I was trying to follow up what I
thought was your suggestion earlier and whence the instructions above.

> 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.)

You do get a prompt when `packages' try to connect in the GUI, but in
the batch mode (as in the Eldev case, where the error happens on a
cloud server somewher in GitHub without the user input) you don't,
though it should be possible to disable programmatically as a possible
work around indeed.

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

Agreed, it is an issue with the latest official precompiled MS-Windows binaries.