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

[Eli Zaretskii]

> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> Date: Sun, 24 Oct 2021 21:30:09 +0100
> Cc: john@rootabega.net, 51038@debbugs.gnu.org, emacs-hoffman@snkmail.com, 
>       Lars Ingebrigtsen <larsi@gnus.org>
> 
> > 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.

You are reading too much into that text.  It doesn't say anywhere that
these binaries are "official', nor even that they are endorsed or
blessed by the project.  I don't think it's reasonable to expect us to
have a disclaimer near any binary distribution of Emacs saying it
isn't "official".  There are more sites out there which distribute
precompiled binaries of Emacs.

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

I wasn't talking about dependencies, I was talking about additional
Emacs-related software that could be installed on the user's machine,
and could affect the detailed instructions.  For example, some of
those additional programs could require the old GnuTLS, so we cannot
easily say "replace with the new one".

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

The only official download for Emacs is the source distribution.  That
is the only distribution that's under the direct responsibility of the
project.

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

If you answer "allow" for that single prompt, telling the NSM to
always trust ELPA, you won't need to answer any more questions, and I
believe the batch operation will also work.