GNU bug report logs - #55858
28.1; process-async-https-with-delay failure

Previous Next

Full log

Message #14 received at 55858 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55858 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#55858: 28.1; process-async-https-with-delay failure
Date: Thu, 09 Jun 2022 10:30:52 +0200

>>>>> On Thu, 09 Jun 2022 08:26:50 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
    >> There are two issues here.  First, there's obviously something I should
    >> do on my system so that the TLS certificate for elpa.gnu.org is
    >> trusted.  I know nothing about TLS certificates and would appreciate
    >> help here.

    Eli> Not sure about Cygwin, but in general on MS-Windows GnuTLS uses the
    Eli> system certificate store to verify certificates.  The particular
    Eli> problem above should be solved by upgrading GnuTLS and perhaps also
    Eli> updating the system certificate store (which should be in general
    Eli> always up to date, but I don't know how that system is maintained).

This might be the Let's Encrypt cross-signing certificate expiry
issue, which is fixed in GnuTLS >= 3.6.14 See eg
<https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/>

    Eli> OTOH, if Cygwin GnuTLS uses the Posix mechanism of certificate stores
    Eli> on disk files, then upgrading the certificate files.

If Iʼm right, itʼs a problem in GnuTLS, not an issue with the
certificate store.

Alternatively, we could just let-bind `network-security-level' to 'low
in that test, which effectively disables the checking.

Robert
-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.