[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ioannis Kappas
Subject: bug#51038: 27.2; ELPA certificate not trusted on Windows
Date: Sun, 24 Oct 2021 19:21:00 +0100

Hi Eli,

On Sun, Oct 24, 2021 at 6:11 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > 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.
> AFAIU, this issue is not with Emacs, it's with GnuTLS.  So all you
> need is download and install a newer GnuTLS, where this problem was
> fixed, in place of the old one.  Emacs should then work with that
> GnuTLS; there's no need to rebuild Emacs itself.
> If you already tried that and it didn't work, please tell the details.

(apologies for being pedantic here, just want tom make sure that any
difference in opinion become clear)

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

I believe you are saying that there is no issue with the latest
official precompiled Gnu Emacs Windows release (say at
because the error is coming from libgnu-3.6.12, a library that Emacs
depends on, and not from the Emacs code.

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


With regards to the suggested workaround, on my Windows machine

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
that redirects to a 404.
2.1.1 Trying to find the artifacts by going to
https://gitlab.com/gnutls/gnutls -> CI/CD -> Pipelines -> click on
pipeline ID (in my case
(quite a mouthful) and replace libgnutls-30.dll with it works.

Which i find it a bit too involved, especially for new users
regardless even if they are magically aware of the root issue?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]