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

[Ioannis Kappas]

On Mon, Oct 25, 2021 at 12:48 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > 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>
> >

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

I believe the perception for the majority of users new or old to Emacs
is that these are the official binaries. As of a random example, the
Emacs Wiki @ https://www.emacswiki.org/emacs/MsWindowsInstallation
reads (the *** are mine):

""" Guidelines for installing Emacs on MS Windows

To install the ***official*** stable binaries:

  Visit https://ftp.gnu.org/gnu/emacs/windows/emacs-27/ (or
https://ftpmirror.gnu.org/emacs/windows/emacs-27/ to use a nearby
mirror). Download the last zip-file ending in x86_64.zip for 64 bit or
i686.zip for 32 bit listed (currently emacs-27.1-x86_64.zip and
emacs-27.1-i686.zip, respectively). You might also want to read the
README file at the same site (not the one inside the zip-file). Once
the zip-file is downloaded, open it using Explorer (slow) or 7zip
(faster) and extract all the files into a directory of your choice
(e.g. c:\packages\emacs-27.1).""

Now, you may argue, anyone can right anything on these websites, but I
am just trying to give out the sentiment what the people think about
these precompiled binaries. I would personally not have thought these
were not official until we had this discussion. I think this
misconception should be addressed somehow, otherwise users might be
left perplexed or unable to use Emacs on Windows to its full
potential. That's my personal opinion btw, you don't have to agree
with it. You are the maintainers after all and your decisions are most
respected.

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

IMHO we have to make this clear somehow. The believe in my opinion is
that people are seeing these binaries as official.

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

In our case, the failing Emacs process is run on a Windows 2019 server
noninteractively somewhere on the GitHub cloud, with no user
intervention so there is no prompt to see the prompt. I figured out
though a hack based on this, It should be possible to include in the
testing script. Thanks for mentioning it.