error: No version of gnu-elpa-keyring-update >= nil is available

[tianywan]

I find the issue #721 (#721) could be reproduced on this version of emacs configuration on RHEL 8.0.
The error "No version of gnu-elpa-keyring-update >= nil is available" is reported during the stage of initiation, and the following error could also be found in the output of "emacs --debug-init":

Debugger entered--Lisp error: (file-error "https://elpa.gnu.org/packages/archive-contents" "Bad Request")
signal(file-error ("https://elpa.gnu.org/packages/archive-contents" "Bad Request"))
package--download-one-archive(("gnu" . "https://elpa.gnu.org/packages/") "archive-contents" nil)
package--download-and-read-archives(nil)
package-refresh-contents()

On the issue #721, I worked around it by replacing "https" with "http" in init-elpa.el, which is not worked for this version any more. I post this problem here because I believe there must be someone who knows the root cause and maybe can give me some help.
Any reply is very appreciated!

The following is some information for reference:

1. I believe this is different from issue Package undo-tree is unavailable and Failed to download 'gnu' archive. Bad request. (Solution included) syl20bnr/spacemacs#12535,
   because I find the rescue method has already been imported into init-elpa.el:

(setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")

2. my emacs version is:

[user1@localhost ~]$ emacs --version
GNU Emacs 26.1
Copyright (C) 2018 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

3. my emacs can open something like "https://www.yahoo.com", but cannot open "https://elpa.gnu.org". This may has little relation to the GFW(Great Firewall of China), because I can open https://elpa.gnu.org from firefox browser.

4. Some thing on ELPA's certificate chains of my certifacates:
   4.1 output of "gnutls-cli-debug"

[user1@localhost.emacs.d]$ gnutls-cli-debug elpa.gnu.org
GnuTLS debug client 3.6.5
Checking elpa.gnu.org:443
whether we need to disable TLS 1.2... no
whether we need to disable TLS 1.1... no
whether we need to disable TLS 1.0... no
whether %NO_EXTENSIONS is required... yes
whether %COMPAT is required... no
for TLS 1.0 (RFC2246) support... yes
for TLS 1.1 (RFC4346) support... yes
for TLS 1.2 (RFC5246) support... yes
for TLS 1.3 (RFC8446) support... yes
|<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
TLS1.2 neg fallback from TLS 1.6 to... TLS1.2
for inappropriate fallback (RFC7507) support... yes
for HTTPS server name... Apache/2.4.38 (Debian)
for certificate chain order... sorted
for safe renegotiation (RFC5746) support... yes
for encrypt-then-MAC (RFC7366) support... yes
for ext master secret (RFC7627) support... yes
for heartbeat (RFC6520) support... no
for version rollback bug in RSA PMS... dunno
for version rollback bug in Client Hello... no
whether the server ignores the RSA PMS version... no
whether small records (512 bytes) are tolerated on handshake... no
whether cipher suites not in SSL 3.0 spec are accepted... yes
whether a bogus TLS record version in the client hello is accepted... yes
whether the server understands TLS closure alerts... yes
whether the server supports session resumption... yes
for anonymous authentication support... no
|<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
for ephemeral Diffie-Hellman support... yes
|<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
for RFC7919 Diffie-Hellman support... no
for ephemeral EC Diffie-Hellman support... yes
for curve SECP256r1 (RFC4492)... yes
for curve SECP384r1 (RFC4492)... yes
for curve SECP521r1 (RFC4492)... yes
for curve X25519 (RFC8422)... yes
for AES-GCM cipher (RFC5288) support... yes
for AES-CCM cipher (RFC6655) support... yes
for AES-CCM-8 cipher (RFC6655) support... yes
for AES-CBC cipher (RFC3268) support... yes
for CAMELLIA-GCM cipher (RFC6367) support... no
for CAMELLIA-CBC cipher (RFC5932) support... yes
for 3DES-CBC cipher (RFC2246) support... no
for ARCFOUR 128 cipher (RFC2246) support... no
|<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
for CHACHA20-POLY1305 cipher (RFC7905) support... yes
for MD5 MAC support... no
for SHA1 MAC support... yes
for SHA256 MAC support... yes
for max record size (RFC6066) support... no
for OCSP status response (RFC6066) support... no

4.2 output of "gnutls-cli elpa.gnu.org":

Processed 148 CA certificate(s).
Resolving 'elpa.gnu.org:443'...
Connecting to '209.51.188.89:443'...

• Certificate type: X.509

• Got a certificate list of 2 certificates.

• Certificate[0] info:

• subject CN=elpa.gnu.org', issuer CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial " ****** ", RSA key 2048 bits, signed using RSA-SHA256, activated 2020-02-04 06:13:39 UTC', expires 2020-05-04 06:13:39 UTC', pin-sha256=" ****** "
  Public Key ID:
  sha1:******
  sha256:******
  Public Key PIN:
  pin-sha256:******

• Certificate[1] info:

• subject CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer CN=DST Root CA X3,O=Digital Signature Trust Co.', serial " ****** ", RSA key 2048 bits, signed using RSA-SHA256, activated 2016-03-17 16:40:46 UTC', expires 2021-03-17 16:40:46 UTC', pin-sha256=" ****** "

• Status: The certificate is trusted.

• Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)

• Options:

• Handshake was completed

• Simple Client Mode:

HTTP/1.1 400 Bad Request
Date: Mon, 23 Mar 2020 08:52:17 GMT
Server: Apache/2.4.38 (Debian)
Content-Length: 297
Connection: close
Content-Type: text/html; charset=iso-8859-1

<title>400 Bad Request</title>

Bad Request

Your browser sent a request that this server could not understand.

---

Apache/2.4.38 (Debian) Server at elpa Port 443 - Peer has closed the GnuTLS connection

4.3 output of emacs with command of M-: (gnutls-available-p)
(ClientHello\ Padding Key\ Share Post\ Handshake\ Auth PSK\ Key\ Exchange\ Modes Cookie Supported\ Versions Early\ Data Pre\ Shared\ Key Se
ssion\ Ticket Record\ Size\ Limit Extended\ Master\ Secret Encrypt-then-MAC ...)

[tianywan]

I find some information on this problem. https://emacs.stackexchange.com/questions/26335/emacs-behind-firewall-cannot-download-packages-from-melpa

[amittendulkar]

I am getting the same issue on RHEL 8. However, I am not inside any firewall. I just spun up an Amazon EC2 RHEL8 instance and cloned the repo.

The command wget https://elpa.gnu.org/packages/archive-contents is downloading the content properly but emacs --debug-init is showing "Bad Request" error. What might be wrong?

ec2-user@ip-10-0-0-228 ~]$ emacs --version
GNU Emacs 26.1
Copyright (C) 2018 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Adding debug-init output,

Debugger entered--Lisp error: (file-error "https://elpa.gnu.org/packages/archive-contents" "Bad Request")
  signal(file-error ("https://elpa.gnu.org/packages/archive-contents" "Bad Request"))
  package--download-one-archive(("gnu" . "https://elpa.gnu.org/packages/") "archive-contents" nil)
  package--download-and-read-archives(nil)
  package-refresh-contents()

Starting with emacs -q and running M-x package-list-packages gave me the below error (copy-pasting from *Messages*),

Loading /usr/share/emacs/site-lisp/site-start.d/desktop-entry-mode-init.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Importing package-keyring.gpg...done
You can run the command `package-list-packages' with M-x pa-l- RET
Package refresh done
error in process sentinel: Error retrieving: https://elpa.gnu.org/packages/archive-contents "incomprehensible buffer" [2 times]

[ncouture]

@tianywan you're in Luck this repository maintainer continues to support as best he can older versions of Emacs.

I know it may not be possible in some environments (mostly corporate environments) to use non-official packages, but I'm really surprised RHEL ships Emacs 26.

Even Debian stable which is recognized to be very stable, now ships Emacs 27.

It may not be good advice to go with Emacs 30.1 if you're not very involved in managing your configuration as it's freshly out and some packages require additional fiddling to work with some of its recent changes, but I would advise you do yourself a favor if you can an upgrade to a newer version of Emacs.

I have been very pleased upgrading to Emacs 30.1 and using @purcell's .emacs.d with some additions, notably gptel.el with support for anthropic API wich continues to blow my mind.

Also, tree-sitter turned out to be so far very well behaved and easy to manage.

Noteworthy: I am primarily a Python/JavaScript/TypeScript user.