Subject: Re: bug#55858: 28.1; process-async-https-with-delay failure

From: Eli Zaretskii <[email-masked]>
Date: Thu, 09 Jun 2022 08:26:50 +0300

> Date: Wed, 8 Jun 2022 18:04:05 -0400
> From: Ken Brown <[email-masked]>
> 
> process-async-https-with-delay in test/src/process-tests.el fails on my
> Cygwin system when run via 'make check' (but not when run via 'emacs
> -batch -l /path/to/test/src/process-tests.el -f
> ert-run-tests-batch-and-exit').  By adding 'TEST_INTERACTIVE=yes' to the
> make invocation, I traced this to a certificate problem together with
> the fact that HOME is set to /nonexistent during 'make check'.
> 
> In more detail, if I run
> 
> make -C test process-tests SELECTOR='process-async-https-with-delay' 
> TEST_INTERACTIVE=yes
> 
> then emacs starts and shows me the following in the *Network Security
> Manager* buffer:
> 
> Certificate information
>    Issued by:          R3
>    Issued to:          CN=elpa.gnu.org
>    Hostname:           elpa.gnu.org
>    Public key:         RSA, signature: RSA-SHA256
>    Session:            TLS1.3, key: ECDHE-RSA, cipher: AES-256-GCM, mac: AEAD
>    Security level:     Medium
>    Valid:              From 2022-05-27 to 2022-08-25
> 
> The TLS connection to elpa.gnu.org:443 is insecure
> for the following reasons:
> 
> * certificate has expired
> * certificate could not be verified
> 
> A minibuffer prompt asks me if I want to continue connecting, and if I
> select 'always', I get a "No such file or directory" error for
> /nonexistent/.emacs.d/network-security.data.  Of course,
> ~/.emacs.d/network-security.data does exist and contains the appropriate
> information about elpa.gnu.org:443 from previous selections of 'always'
> outside of 'make check'.
> 
> 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.

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

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