#969971 emacs: Installation of packages from GNU ELPA fails due to incorrect handling of TLS1.3

Package:
emacs
Source:
emacs
Submitter:
Ryo IGARASHI
Date:
2024-02-26 13:15:04 UTC
Severity:
grave
Tags:
#969971#5
Date:
2020-09-09 14:33:57 UTC
From:
To:
Dear Maintainer,

This bug seems related to #942413, but a different bug.
After updating emacs-gtk to 1:26.1+1-3.2+deb10u1, installing packages
from GNU ELPA still fails even if verifying by GnuPG succeeds.

It seems that TLS1.3 handling is broken before 26.3[1].

I can workaround by setting:
(setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")
in ~/.emacs.d/init.el, but I believe this should be handled by package.

This issue can be fixed by:
1. add above setq in system-wide init file
2. backport patch in C code,
but I prefer option 2.

Steps to reproduce:

1. Invoke `emacs` with attached init.el
2. `M-x list-packages` gives following error:
error in process sentinel: Error retrieving: https://elpa.gnu.org/packages/archive-contents "incomprehensible buffer" [2 times]
3. eval `(setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")`
4. `M-x list-packages` works properly

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341

Best regards,
- --
Ryo Igarashi, Ph.D.
rigarash@gmail.com

- -- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.104-microsoft-standard (SMP w/8 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages emacs depends on:
ii  emacs-gtk  1:26.1+1-3.2+deb10u1

emacs recommends no packages.

emacs suggests no packages.

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iIkEARYKADEWIQSQVQWnJ6dEuIxNmESAtgFFC/hXNwUCX1jnzhMccmlnYXJhc2hA
Z21haWwuY29tAAoJEIC2AUUL+Fc3wL0A/jRiGtslRjCy6AVNDtlLrTI52ofMhBJf
JLegBhXizedsAQDlqR4yP+k1p7hy4j65iIFUPzQCcY097+fM0bqDCEPQDw==
=pzFi
-----END PGP SIGNATURE-----

#969971#10
Date:
2021-01-19 20:31:07 UTC
From:
To:
Hello,

I am also affected by the same bug in Debian stable (buster). How can we
deal with this?

#969971#15
Date:
2021-01-19 23:32:02 UTC
From:
To:
The bug report you are responding to includes instructions for working around the problem. Do those not work for you?

/* era */

#969971#20
Date:
2021-01-20 03:56:37 UTC
From:
To:
Hello era,

Thank you for your reply. Yes, the workaround works, but I feel that
this is still a bug in the package. I'm also not sure how safe it is to
disable TLS 1.3.

I believe Emacs version 26.3 fixes this. I don't know how updating
packages works in stable releases, or if it is even possible. I am new
to Debian.

Regards.

#969971#25
Date:
2021-01-20 06:07:42 UTC
From:
To:
The following is based on my -- possibly limited -- understanding based on reading through the bug reports around this.

Your options at this point are then, in no particular order;

* Live without ELPA (easy if you can live with base Emacs; hard if you need ELPA packages);
* Find or create a backport of the TLS1.3 handling fix yourself, and use that instead of the Debian-packaged Emacs;
* Turn off TLS1.3 and take steps to mitigate the risks (not sure what exactly that would look like in practice)

In normal circumstances, the "stable" version does not get updates except for critical security fixes. However, there was already one attempt at fixing this particular bug which however doesn't seem to work satisfactorily, which is apparently what caused this bug to be submitted.  There definitely won't be a 26.3 in Buster, but perhaps the maintainer would still like to take another stab at providing a backport for 26.1 which actually works, and release that fix to Buster.

Perhaps see also the discussion in the linked original bug https://bugs.debian.org/942413

/* era */

#969971#30
Date:
2021-01-21 00:29:41 UTC
From:
To:
I appreciate your detailed explanation, era. Thank you.
#969971#39
Date:
2024-02-26 13:10:27 UTC
From:
To:
According to the bug log this was fixed in 2020, but the bug wasn't
closed for reasons that are unclear. Close it now.