* 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 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
* 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
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
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.