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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55858 in the body.
You can then email your comments to 55858 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1; process-async-https-with-delay failure
Date: Wed, 8 Jun 2022 18:04:05 -0400

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.

Second, I think it's a bug that the test is causing /nonexistent to be
accessed.  Maybe it would make more sense for the test to be skipped if
the certificate can't be verified.

Ken

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 55858 <at> debbugs.gnu.org
Subject: Re: bug#55858: 28.1; process-async-https-with-delay failure
Date: Thu, 09 Jun 2022 08:26:50 +0300

> Date: Wed, 8 Jun 2022 18:04:05 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> 
> 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.

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

From: Achim Gratz <Stromeko <at> Nexgo.DE>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#55858: 28.1; process-async-https-with-delay failure
Date: Thu, 9 Jun 2022 08:44:52 +0200

Am 09.06.2022 um 00:04 schrieb Ken Brown:
> 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.

Install ca-certificates-letsencrypt perhaps?

-- 
Achim.

(on the road :-)

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

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Achim Gratz <Stromeko <at> Nexgo.DE>, 55858 <at> debbugs.gnu.org
Subject: Re: bug#55858: 28.1; process-async-https-with-delay failure
Date: Thu, 9 Jun 2022 07:17:01 -0400

On 6/9/2022 2:44 AM, Achim Gratz wrote:
> Am 09.06.2022 um 00:04 schrieb Ken Brown:
>> 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.
> 
> Install ca-certificates-letsencrypt perhaps?

That fixed it.  Thanks!

Ken

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 55858 <at> debbugs.gnu.org
Subject: Re: bug#55858: 28.1; process-async-https-with-delay failure
Date: Thu, 09 Jun 2022 15:07:32 +0200

Ken Brown <kbrown <at> cornell.edu> writes:

> Second, I think it's a bug that the test is causing /nonexistent to be
> accessed.  Maybe it would make more sense for the test to be skipped if
> the certificate can't be verified.

I'm not sure that test should be in our repertoire at all.  We're pretty
strict about not "phoning home" (because of privacy concerns), and while
this is wholly innocuous in this case, it is surprising that saying
"make check" will inform the people running elpa.gnu.org that you're
doing so.

(And as a practical matter, bugs in external network connections/sites
shouldn't make a test fail.)

I think that test should be removed, or rewritten to be wholly local, so
I've added Mattias to the CC, since he added that test.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 55858 <at> debbugs.gnu.org
Subject: Re: bug#55858: 28.1; process-async-https-with-delay failure
Date: Mon, 11 Jul 2022 13:20:10 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I think that test should be removed, or rewritten to be wholly local, so
> I've added Mattias to the CC, since he added that test.

I've moved it to test/manual/process-callout-tests.el.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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