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

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

[Ken Brown]

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

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

[Eli Zaretskii]

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

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

[Achim Gratz]

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

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

[Robert Pluim]

>>>>> On Thu, 09 Jun 2022 08:26:50 +0300, Eli Zaretskii <eliz@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
-- 

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

[Ken Brown]

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

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

[Lars Ingebrigtsen]

Ken Brown <kbrown@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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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