GNU bug report logs - #48103
28.0.50; tls connection failing on invoking package-list-packages (and other operations)

Previous Next

To reply to this bug, email your comments to 48103 AT debbugs.gnu.org.

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

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

From: wilde <at> sha-bang.de
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; tls connection failing on invoking package-list-packages
 (and other operations)
Date: Thu, 29 Apr 2021 16:45:59 +0200

* What I do:

emacs -Q
M-: (setq gnutls-log-level 1) RET
M-x package-list-packages RET

* The problem:

The update of the packages fails, from the *Messages* buffer:

Importing package-keyring.gpg...done
gnutls.c: [1] (Emacs) connecting to host: elpa.gnu.org
gnutls.c: [1] (Emacs) allocating credentials
gnutls.c: [1] (Emacs) setting the trustfile:  /etc/ssl/certs/ca-certificates.crt
gnutls.c: [1] (Emacs) gnutls callbacks
gnutls.c: [1] (Emacs) gnutls_init
gnutls.c: [1] (Emacs) got non-default priority string: NORMAL:%DUMBFW
gnutls.c: [1] (Emacs) setting the priority string
gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again.
gnutls.c: [1] (Emacs) connecting to host: elpa.nongnu.org
gnutls.c: [1] (Emacs) allocating credentials
gnutls.c: [1] (Emacs) setting the trustfile:  /etc/ssl/certs/ca-certificates.crt
gnutls.c: [1] (Emacs) gnutls callbacks
gnutls.c: [1] (Emacs) gnutls_init
gnutls.c: [1] (Emacs) got non-default priority string: NORMAL:%DUMBFW
gnutls.c: [1] (Emacs) setting the priority string
gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again. [5 times]
error in process sentinel: Error retrieving: https://elpa.nongnu.org/nongnu/archive-contents (error connection-failed "connect" :host "elpa.nongnu.org" :service 443) [2 times]
Package refresh done
error in process sentinel: Error retrieving: https://elpa.gnu.org/packages/archive-contents (error connection-failed "connect" :host "elpa.gnu.org" :service 443) [2 times]

* Additional information:

M-x eww RET
Enter URL or keywords: https://elpa.gnu.org/packages/archive-contents

Works -- at least some times, hitting `g' a few times is might be
needed.

I am running emacs on a rather slow [Intel(R) Atom(TM) CPU N270 @
1.60GHz] NetBSD 9.1 system.

(I'm running various rather similar builds of Emacs on faster GNU/Linux
systems which don't show this problem.  So this seems to be either
related to NetBSD or to the rather old hardware.)

cheers
sascha


In GNU Emacs 28.0.50 (build 1, i386-unknown-netbsdelf9.1)
 of 2021-04-28 built on tammy.lan.sha-bang.de
Repository revision: 0c7f1e2e42d6bf9f95e88c02d4e1ed9cb40693d8
Repository branch: master
System Description: NetBSD tammy.lan.sha-bang.de 9.1 NetBSD 9.1 (GENERIC) #0: Sun Oct 18 19:24:30 UTC 2020  mkrepro <at> mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC i386

Configured using:
 'configure --disable-autodepend --without-ns --with-modules
 --without-gconf --without-gsettings --with-native-compilation
 --without-x --with-x-toolkit=no --without-xft --without-lcms2
 --without-rsvg 'CFLAGS=-O3 -mtune=native -march=native'
 'LDFLAGS=-L/usr/local/lib -L/usr/lib -L/usr/pkg/lib
 -Wl,-R/usr/local/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib''

Configured features:
DBUS GMP GNUTLS LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE PDUMPER SOUND
THREADS ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: eww

Minor modes in effect:
  mouse-wheel-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail mm-archive message dired
dired-loaddefs rfc822 mml mml-sec epa derived mailabbrev gmm-utils
mailheader mm-decode mm-bodies mm-encode format-spec eww xdg url-queue
thingatpt shr kinsoku image svg xml dom mm-url gnus nnheader gnus-util
rmail rmail-loaddefs text-property-search time-date mail-utils wid-edit
misearch multi-isearch mule-util gnutls network-stream url-http
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw
nsm rmc puny url-cache url-auth epg epg-config finder-inf package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap url-handlers url-parse
auth-source eieio eieio-core eieio-loaddefs password-cache json map
url-vars comp comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra
help-mode tool-bar seq cl-loaddefs cl-lib term/rxvt term/xterm xterm
byte-opt gv bytecomp byte-compile cconv jka-compr regexp-opt mwheel
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind kqueue multi-tty
make-network-process nativecomp emacs)

Memory information:
((conses 8 169120 16723)
 (symbols 24 11816 1)
 (strings 16 44676 3141)
 (string-bytes 1 1210362)
 (vectors 8 20945)
 (vector-slots 4 387505 25090)
 (floats 8 85 418)
 (intervals 28 2285 284)
 (buffers 572 24))

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: wilde <at> sha-bang.de
Cc: 48103 <at> debbugs.gnu.org
Subject: Re: bug#48103: 28.0.50; tls connection failing on invoking
 package-list-packages (and other operations)
Date: Sun, 02 May 2021 09:49:04 +0200

wilde <at> sha-bang.de writes:

> gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again. [5 times]
> error in process sentinel: Error retrieving: https://elpa.nongnu.org/nongnu/archive-contents (error connection-failed "connect" :host "elpa.nongnu.org" :service 443) [2 times]

[...]

> I am running emacs on a rather slow [Intel(R) Atom(TM) CPU N270 @
> 1.60GHz] NetBSD 9.1 system.

I seem to remember there being some issues in the gnutls connection algo
when the host is particularly slow, but I've been poking around, and I
can't find the details.  Does anybody else remember?

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

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

From: wilde <at> sha-bang.de
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 48103 <at> debbugs.gnu.org
Subject: Re: bug#48103: 28.0.50; tls connection failing on invoking
 package-list-packages (and other operations)
Date: Mon, 03 May 2021 12:13:04 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> wilde <at> sha-bang.de writes:
>
>> gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again. [5 times]
>> error in process sentinel: Error retrieving:
>> https://elpa.nongnu.org/nongnu/archive-contents (error
>> connection-failed "connect" :host "elpa.nongnu.org" :service 443) [2
>> times]
>
> [...]
>
>> I am running emacs on a rather slow [Intel(R) Atom(TM) CPU N270 @
>> 1.60GHz] NetBSD 9.1 system.

Hi *,

It turns out that setting 'gnutls-algorithm-priority to
"normal:-vers-tls1.3" fixes the problem for me:
  (setq gnutls-algorithm-priority "normal:-vers-tls1.3")


The question that still remains is: why is this customization necessary?
And why is it only necessary on this NetBSD system but on none of my
GNU/Linux systems?

FWIW: 
  gnutls-cli elpa.nongnu.org 443
on the NetBSD system connects without any issues...

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: wilde <at> sha-bang.de
Cc: 48103 <at> debbugs.gnu.org
Subject: Re: bug#48103: 28.0.50; tls connection failing on invoking
 package-list-packages (and other operations)
Date: Tue, 04 May 2021 11:01:49 +0200

wilde <at> sha-bang.de writes:

> It turns out that setting 'gnutls-algorithm-priority to
> "normal:-vers-tls1.3" fixes the problem for me:
>   (setq gnutls-algorithm-priority "normal:-vers-tls1.3")
>
> The question that still remains is: why is this customization necessary?

It shouldn't be -- gnutls should degrade gracefully here, and your test
with gnutls-cli seems to indicate that it does.  So it sounds like
there's a bug in how Emacs interfaces with the gnutls library in this
situation.

> And why is it only necessary on this NetBSD system but on none of my
> GNU/Linux systems?

Perhaps the version of gnutls on NetBSD doesn't support TLS 1.3?

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

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

From: wilde <at> sha-bang.de
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 48103 <at> debbugs.gnu.org
Subject: Re: bug#48103: 28.0.50; tls connection failing on invoking
 package-list-packages (and other operations)
Date: Tue, 04 May 2021 15:14:37 +0200

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

> wilde <at> sha-bang.de writes:
>
>> It turns out that setting 'gnutls-algorithm-priority to
>> "normal:-vers-tls1.3" fixes the problem for me:
>>   (setq gnutls-algorithm-priority "normal:-vers-tls1.3")
>>
>> The question that still remains is: why is this customization
>> necessary?
>
> It shouldn't be -- gnutls should degrade gracefully here, and your
> test
> with gnutls-cli seems to indicate that it does.  So it sounds like
> there's a bug in how Emacs interfaces with the gnutls library in this
> situation.

I agree, that this looks like a bug.

>> And why is it only necessary on this NetBSD system but on none of my
>> GNU/Linux systems?
>
> Perhaps the version of gnutls on NetBSD doesn't support TLS 1.3?

On my NetBSD system:

% gnutls-cli -l | grep -i tls1.3
TLS_AES_128_GCM_SHA256             0x13, 0x01      TLS1.3
TLS_AES_256_GCM_SHA384             0x13, 0x02      TLS1.3
TLS_CHACHA20_POLY1305_SHA256       0x13, 0x03      TLS1.3
TLS_AES_128_CCM_SHA256             0x13, 0x04      TLS1.3
TLS_AES_128_CCM_8_SHA256           0x13, 0x05      TLS1.3
Protocols: VERS-TLS1.0, VERS-TLS1.1, VERS-TLS1.2, VERS-TLS1.3, VERS-DTLS0.9, 
VERS-DTLS1.0, VERS-DTLS1.2

This output is identical to the output I get on my GNU/Linux system
where the system does not exist.  So I'd assume the TLS 1.3 support does
not differ...

Thanks for your support,

sascha

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: wilde <at> sha-bang.de
Cc: 48103 <at> debbugs.gnu.org
Subject: Re: bug#48103: 28.0.50; tls connection failing on invoking
 package-list-packages (and other operations)
Date: Wed, 05 May 2021 11:20:27 +0200

wilde <at> sha-bang.de writes:

>> Perhaps the version of gnutls on NetBSD doesn't support TLS 1.3?
>
> On my NetBSD system:
>
> % gnutls-cli -l | grep -i tls1.3
> TLS_AES_128_GCM_SHA256             0x13, 0x01      TLS1.3
> TLS_AES_256_GCM_SHA384             0x13, 0x02      TLS1.3
> TLS_CHACHA20_POLY1305_SHA256       0x13, 0x03      TLS1.3
> TLS_AES_128_CCM_SHA256             0x13, 0x04      TLS1.3
> TLS_AES_128_CCM_8_SHA256           0x13, 0x05      TLS1.3
> Protocols: VERS-TLS1.0, VERS-TLS1.1, VERS-TLS1.2, VERS-TLS1.3, VERS-DTLS0.9, 
> VERS-DTLS1.0, VERS-DTLS1.2
>
> This output is identical to the output I get on my GNU/Linux system
> where the system does not exist.  So I'd assume the TLS 1.3 support does
> not differ...

Doesn't sound like it, no, so I'm guessing there's something
timing-related and a problem with retries.  Unfortunately, I'm not able
to build Emacs at all under Netbsd 9.0 (which is the version I have
here), so I'll have to install a new VM with 9.1 to do some testing.

That might take a while, though, so if somebody else can poke at this,
that'd be nice.  :-)

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

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: wilde <at> sha-bang.de, 48103 <at> debbugs.gnu.org
Subject: Re: bug#48103: 28.0.50; tls connection failing on invoking
 package-list-packages (and other operations)
Date: Wed, 05 May 2021 14:55:16 +0200

>>>>> On Wed, 05 May 2021 11:20:27 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> said:

    Lars> wilde <at> sha-bang.de writes:
    >>> Perhaps the version of gnutls on NetBSD doesn't support TLS 1.3?
    >> 
    >> On my NetBSD system:
    >> 
    >> % gnutls-cli -l | grep -i tls1.3
    >> TLS_AES_128_GCM_SHA256             0x13, 0x01      TLS1.3
    >> TLS_AES_256_GCM_SHA384             0x13, 0x02      TLS1.3
    >> TLS_CHACHA20_POLY1305_SHA256       0x13, 0x03      TLS1.3
    >> TLS_AES_128_CCM_SHA256             0x13, 0x04      TLS1.3
    >> TLS_AES_128_CCM_8_SHA256           0x13, 0x05      TLS1.3
    >> Protocols: VERS-TLS1.0, VERS-TLS1.1, VERS-TLS1.2, VERS-TLS1.3, VERS-DTLS0.9, 
    >> VERS-DTLS1.0, VERS-DTLS1.2
    >> 
    >> This output is identical to the output I get on my GNU/Linux system
    >> where the system does not exist.  So I'd assume the TLS 1.3 support does
    >> not differ...

    Lars> Doesn't sound like it, no, so I'm guessing there's something
    Lars> timing-related and a problem with retries.  Unfortunately, I'm not able
    Lars> to build Emacs at all under Netbsd 9.0 (which is the version I have
    Lars> here), so I'll have to install a new VM with 9.1 to do some testing.

    Lars> That might take a while, though, so if somebody else can poke at this,
    Lars> that'd be nice.  :-)

I had a quick look at what gnutls-cli does differently, and it sets a
timeout on the handshake, but that then requires you to supply a
timeout callback, which ends up calling select. gnutls-cli sets a
timeout of 40 seconds, but I guess we could set something shorter, but
then I worry about the effect of calling select from outside
wait_reading_process_output.

Robert
-- 

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

From: wilde <at> sha-bang.de
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 48103 <at> debbugs.gnu.org
Subject: Re: bug#48103: 28.0.50; tls connection failing on invoking
 package-list-packages (and other operations)
Date: Wed, 05 May 2021 16:24:54 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> wilde <at> sha-bang.de writes:
> [...]  Unfortunately, I'm not able
> to build Emacs at all under Netbsd 9.0 (which is the version I have
> here), so I'll have to install a new VM with 9.1 to do some testing.

Full disclosure: I'm building using gcc10 also build by my self.
(And currently I'm linking against a gnutls version also build by my self
as this was the first idea I had to fix the problem at hand -- which did
not change the problem)

In case this helps I could tar up provide my entire /usr/local
(containing my emacs, gcc and gnutls).

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: wilde <at> sha-bang.de, 48103 <at> debbugs.gnu.org
Subject: Re: bug#48103: 28.0.50; tls connection failing on invoking
 package-list-packages (and other operations)
Date: Thu, 06 May 2021 11:13:04 +0200

Robert Pluim <rpluim <at> gmail.com> writes:

> I had a quick look at what gnutls-cli does differently, and it sets a
> timeout on the handshake, but that then requires you to supply a
> timeout callback, which ends up calling select.

Right -- and in Emacs we're just polling on EAGAIN, perhaps?

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

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: wilde <at> sha-bang.de, 48103 <at> debbugs.gnu.org
Subject: Re: bug#48103: 28.0.50; tls connection failing on invoking
 package-list-packages (and other operations)
Date: Thu, 06 May 2021 14:59:51 +0200

>>>>> On Thu, 06 May 2021 11:13:04 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> said:

    Lars> Robert Pluim <rpluim <at> gmail.com> writes:
    >> I had a quick look at what gnutls-cli does differently, and it sets a
    >> timeout on the handshake, but that then requires you to supply a
    >> timeout callback, which ends up calling select.

    Lars> Right -- and in Emacs we're just polling on EAGAIN, perhaps?

Essentially, yes. I took a poke at copying what gnutls-cli does, but
itʼs broken TLS connections to some sites (eg gnu.org). It may end up
not being a small change (ie we may have to add in custom pull/push
functions rather than just a timeout function).

Robert
-- 

Previous Next

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