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

[Ioannis Kappas]

Hi all,

doublep/eldev (the Elisp Development Tool) is just an example of a
project  that has been affected by this issue and has taken some time
and serious effort to figure out what was going wrong:
https://github.com/doublep/eldev/issues/55. The CI running the eldev
test suit on GitHub Windows 2019 servers, which involved downloading
packages from MELPA, suddenly started to fail one day when connecting
to stable.melpa.org. The same tests passed on Linux/MacOs builds. I am
sure there are many more other such instances, either projects or just
users that are affected by it, and are perplexed with the current
situation without having knowledge of the root cause.

May I please argue that this should be at least acknowledged as an
important issue with the latest official GNU emacs 27.2 binary
MS-Windows release as advertised in the `GNU Emacs Download & Install
page' @  https://www.gnu.org/software/emacs/download.html, under
`Nonfree systems`->Windows:

"""GNU Emacs for Windows can be downloaded from a nearby GNU mirror;
or the main GNU FTP server"""

Where `GNU mirror points` to
http://ftp.gnu.org/gnu/emacs/windows/emacs-27/, with the affected
emacs 27.2 releases dated on 2021-Mar-31.

The issue is that the *latest official Gnu Emacs windows binary
releases*, as of today, at the official GNU Emacs download site are
*bundled* with gnutls-3.6.12 which is susceptible to GnuTLS bug#1008
(titled as Handle expiration of AddTrust root certificate (urgent) --
https://gitlab.com/gnutls/gnutls/-/issues/1008) which refuses
connections to sites with valid certificates whose issuer consist of
dual certificates of which one has expired but the other is
not-expired i.e. valid. As such, the official precompiled Emacs 27.2
Windows binaries cannot connect to these sites, which severely
compromising Emacs functionality, with preventing Emacs connecting to
package archives such as ELPA or MELPA being the most prevailing
example.

Thus, I advocate, that the latest official precompiled Gnu Emacs
MS-Windows binaries have a serious issue (caused by a bug in the
GnuTLS version they are bundled with), that either needs to be
addressed or a workaround needs to be suggested somewhere in the
download/install instructions.

For completion I list the available options discussed in this thread/I
can think of with any disadvantages I can think of:

1. Fix: Release new precompiled Emacs 27.2 binary versions to the
official site bundled with a GnuTLS version that has GnuTLS#1008 fix,
i.e. with version >= 3.6.14 (is this likely to be a release
nightmare?)
2. Fix: Wait until the next release (I believe 28.x release is around
the corner?). This leaves Emacs users which rely on the latest
official build vulnerable; i.e. users that follow the official
instructions and don't know what MSYS2 is or how to use it or can't be
bothered -- this is probably the majority of nontechnical users -- or
users in systems behind corporate firewalls that do not permit install
of third party tools msys2/chocolately/scoop, or users in remote
servers with preinstalled version of latest emacs version -- for
example GitHub windows 2019 build/test farms.
3. Work around: Document the issue somewhere that the a prospective
user can't miss (e.g. official download page or the readme document
alongside the binaries, anything else?), with workarounds being
3.1 Update windows certificate store to remove expired certificate as
mentioned in this thread (not sure how this would work, how do you
users find the list of the ones that expired? Does it require special
permission to remove certs? I suppose `Let's encrypt' issuers
certificates are not the only one affected, they may be more either
now or down the line).
3.2 use MSYS2 to build (pickup?) a 27.2 version with the latest GnuTLS
lib (or chocolatey, or scoop perhaps if such version exist there).
Though user might not have the technical background to do so or the
host is restricted in respect to the tools that can be installed
(systems behind corporate firewalls) or the target system is a server
with limited access as to the choice of tools that can be installed
(e.g. custom build Windows 2019 github server farms).
4 Work around: the same as #3 but without updating instructions about
the problem or how to fix it. Leaves users who rely on the latest
official releases without knowledge of this issue in the most
vulnerable and perplexed for them situation.

Thank you