unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)
@ 2021-04-29 14:45 wilde
  2021-05-02  7:49 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 10+ messages in thread
From: wilde @ 2021-04-29 14:45 UTC (permalink / raw)
  To: 48103


* 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@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))





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)
  2021-04-29 14:45 bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations) wilde
@ 2021-05-02  7:49 ` Lars Ingebrigtsen
  2021-05-03 10:13   ` wilde
  0 siblings, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-02  7:49 UTC (permalink / raw)
  To: wilde; +Cc: 48103

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)
  2021-05-02  7:49 ` Lars Ingebrigtsen
@ 2021-05-03 10:13   ` wilde
  2021-05-04  9:01     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 10+ messages in thread
From: wilde @ 2021-05-03 10:13 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 48103

Lars Ingebrigtsen <larsi@gnus.org> wrote:
> wilde@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...





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)
  2021-05-03 10:13   ` wilde
@ 2021-05-04  9:01     ` Lars Ingebrigtsen
  2021-05-04 13:14       ` wilde
  0 siblings, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-04  9:01 UTC (permalink / raw)
  To: wilde; +Cc: 48103

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)
  2021-05-04  9:01     ` Lars Ingebrigtsen
@ 2021-05-04 13:14       ` wilde
  2021-05-05  9:20         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 10+ messages in thread
From: wilde @ 2021-05-04 13:14 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 48103

Lars Ingebrigtsen <larsi@gnus.org> wrote:

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)
  2021-05-04 13:14       ` wilde
@ 2021-05-05  9:20         ` Lars Ingebrigtsen
  2021-05-05 12:55           ` Robert Pluim
  2021-05-05 14:24           ` wilde
  0 siblings, 2 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-05  9:20 UTC (permalink / raw)
  To: wilde; +Cc: 48103

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)
  2021-05-05  9:20         ` Lars Ingebrigtsen
@ 2021-05-05 12:55           ` Robert Pluim
  2021-05-06  9:13             ` Lars Ingebrigtsen
  2021-05-05 14:24           ` wilde
  1 sibling, 1 reply; 10+ messages in thread
From: Robert Pluim @ 2021-05-05 12:55 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: wilde, 48103

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

    Lars> wilde@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
-- 





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)
  2021-05-05  9:20         ` Lars Ingebrigtsen
  2021-05-05 12:55           ` Robert Pluim
@ 2021-05-05 14:24           ` wilde
  1 sibling, 0 replies; 10+ messages in thread
From: wilde @ 2021-05-05 14:24 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 48103

Lars Ingebrigtsen <larsi@gnus.org> wrote:
> wilde@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).





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)
  2021-05-05 12:55           ` Robert Pluim
@ 2021-05-06  9:13             ` Lars Ingebrigtsen
  2021-05-06 12:59               ` Robert Pluim
  0 siblings, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-06  9:13 UTC (permalink / raw)
  To: Robert Pluim; +Cc: wilde, 48103

Robert Pluim <rpluim@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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)
  2021-05-06  9:13             ` Lars Ingebrigtsen
@ 2021-05-06 12:59               ` Robert Pluim
  0 siblings, 0 replies; 10+ messages in thread
From: Robert Pluim @ 2021-05-06 12:59 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: wilde, 48103

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

    Lars> Robert Pluim <rpluim@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
-- 





^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-05-06 12:59 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-29 14:45 bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations) wilde
2021-05-02  7:49 ` Lars Ingebrigtsen
2021-05-03 10:13   ` wilde
2021-05-04  9:01     ` Lars Ingebrigtsen
2021-05-04 13:14       ` wilde
2021-05-05  9:20         ` Lars Ingebrigtsen
2021-05-05 12:55           ` Robert Pluim
2021-05-06  9:13             ` Lars Ingebrigtsen
2021-05-06 12:59               ` Robert Pluim
2021-05-05 14:24           ` wilde

unofficial mirror of bug-gnu-emacs@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-bugs/0 emacs-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-bugs emacs-bugs/ https://yhetil.org/emacs-bugs \
		bug-gnu-emacs@gnu.org
	public-inbox-index emacs-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.bugs
	nntp://news.gmane.io/gmane.emacs.bugs


code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git