GNU Elpa and Emacs 25.3

GNU Elpa and Emacs 25.3

[Paul Pogonyshev]

I cannot access GNU ELPA archive with Emacs 25.3.  Here is a shell
command I created for testing:

    emacs-25.3 --batch --eval "(let ((debug-on-error t)
(package-user-dir \"/tmp/elpa\") \
                                     (package-archives '((\"gnu\" .
\"https://elpa.gnu.org/packages/\")))) \
                                 (when (file-exists-p
package-user-dir) (delete-directory package-user-dir t)) \
                                 (package-initialize) \
                                 (package-refresh-contents))"

It fails with

    (file-error "https://elpa.gnu.org/packages/archive-contents" "Bad Request")

for me.  Also fails if I replace "https" with "http" in the command,
though with a different error.

For comparison all of this works fine:

* The command with different Emacs version: 24.5, 26.3 and 28.0.50
  (trunk).

* The command after replacing "https" with "http" with different Emacs
  version: 24.5, 26.3 and 28.0.50 (trunk).

* Any Emacs version I have, _including_ 25.3, if I replace archive
  with "https://melpa.org/packages/" (also with "http" instead of
  "https").

In other words, it only fails with Emacs 25.3 and GNU ELPA for me.

Can someone verify this?  Does someone know what's going on?

Paul

Re: GNU Elpa and Emacs 25.3

[Noam Postavsky]

On Sat, 25 Jan 2020 at 09:55, Paul Pogonyshev <pogonyshev@gmail.com> wrote:
>
>     (file-error "https://elpa.gnu.org/packages/archive-contents" "Bad Request")
>
> for me.  Also fails if I replace "https" with "http" in the command,
> though with a different error.

The https failure is Bug#36749, though I'm surprised to hear that it
fails with plain http as well.

> * The command with different Emacs version: 24.5, 26.3 and 28.0.50
>   (trunk).

Is your 24.5 Emacs linked against an older version of libgnutls?
Otherwise I would expect it to have the same problem.

Re: GNU Elpa and Emacs 25.3

[Paul Pogonyshev]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

> The https failure is Bug#36749, though I'm surprised to hear that it
> fails with plain http as well.

It fails with a different error:

    (bad-signature "archive-contents.sig")

Also get this error if I apply the workaround suggested in that bugreport.
So, the workaround doesn't help here. Can it be that the signature file
is inherited from some other run, i.e. that deleting `/tmp/elpa' is not
enough to achieve a "clean state"?

> Is your 24.5 Emacs linked against an older version of libgnutls?
> Otherwise I would expect it to have the same problem.

Quite possible.  25.3 is self-compiled, while 24.5 is installed from the OS
(Debian) repository.  I didn't manage to compile anything earlier than
25.3 due to various errors.

Paul

On Sat, 25 Jan 2020 at 16:33, Noam Postavsky <npostavs@gmail.com> wrote:

> On Sat, 25 Jan 2020 at 09:55, Paul Pogonyshev <pogonyshev@gmail.com>
> wrote:
> >
> >     (file-error "https://elpa.gnu.org/packages/archive-contents" "Bad
> Request")
> >
> > for me.  Also fails if I replace "https" with "http" in the command,
> > though with a different error.
>
> The https failure is Bug#36749, though I'm surprised to hear that it
> fails with plain http as well.
>
> > * The command with different Emacs version: 24.5, 26.3 and 28.0.50
> >   (trunk).
>
> Is your 24.5 Emacs linked against an older version of libgnutls?
> Otherwise I would expect it to have the same problem.
>

[-- Attachment #2: Type: text/html, Size: 2998 bytes --]

Re: GNU Elpa and Emacs 25.3

[Noam Postavsky]

On Sat, 25 Jan 2020 at 10:48, Paul Pogonyshev <pogonyshev@gmail.com> wrote:

>     (bad-signature "archive-contents.sig")
>
> Also get this error if I apply the workaround suggested in that bugreport.
> So, the workaround doesn't help here.

It is helping, but now you are encountering Bug#35534. See also
https://elpa.gnu.org/packages/gnu-elpa-keyring-update.html

Re: GNU Elpa and Emacs 25.3

[Paul Pogonyshev]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

Thank you. I guess I was confused by its only failing on Emacs 25.3 and
not 24.5 (but only because the workaround is already applied in Debian
archive, I guess) or 26.3. Should have searched more.

Paul

On Sat, 25 Jan 2020 at 21:05, Noam Postavsky <npostavs@gmail.com> wrote:

> On Sat, 25 Jan 2020 at 10:48, Paul Pogonyshev <pogonyshev@gmail.com>
> wrote:
>
> >     (bad-signature "archive-contents.sig")
> >
> > Also get this error if I apply the workaround suggested in that
> bugreport.
> > So, the workaround doesn't help here.
>
> It is helping, but now you are encountering Bug#35534. See also
> https://elpa.gnu.org/packages/gnu-elpa-keyring-update.html
>

[-- Attachment #2: Type: text/html, Size: 1209 bytes --]

Re: GNU Elpa and Emacs 25.3

[Paul Pogonyshev]

[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]

Sorry to bother again, but now I run into a different problem with this. I
set `gnutls-algorithm-priority' to "NORMAL:-VERS-TLS1.3" as suggested in
that bugreport. This does work fine locally. However, when I use the same
code on Travis CI for automated testing, I get the following error:

     gnutls.c: [1] (Emacs) connecting to host: stable.melpa.org
     gnutls.c: [1] (Emacs) allocating credentials
     gnutls.c: [2] (Emacs) allocating x509 credentials
     gnutls.c: [2] (Emacs) using default verification flags
     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:-VERS-TLS1.3
     gnutls.c: [1] (Emacs) setting the priority string
     gnutls.c: [2] ASSERT: gnutls_priority.c:832

     gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
NORMAL:-VERS-TLS1.3 :hostname stable.melpa.org :loglevel 2 :min-prime-bits
256 :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist
nil :verify-flags nil :verify-error nil :callbacks nil)
     Package refresh done
     Debugger entered--Lisp error: (gnutls-error #<process stable.melpa.org<1>>
-50)
       signal(gnutls-error (#<process stable.melpa.org<1>> -50))

Travis CI (Ubuntu distribution Trusty) has an ancient GnuTLS version
2.12.6. As far as I understand, it doesn't know about TLS1.3 and therefore
the attempt to disable it fails.

Is there a way to use "NORMAL:-VERS-TLS1.3" in "do not fail" mode? Maybe I
could somehow query if the library knows about 1.3 first?

Paul

On Sat, 25 Jan 2020 at 16:33, Noam Postavsky <npostavs@gmail.com> wrote:

> On Sat, 25 Jan 2020 at 09:55, Paul Pogonyshev <pogonyshev@gmail.com>
> wrote:
> >
> >     (file-error "https://elpa.gnu.org/packages/archive-contents" "Bad
> Request")
> >
> > for me.  Also fails if I replace "https" with "http" in the command,
> > though with a different error.
>
> The https failure is Bug#36749, though I'm surprised to hear that it
> fails with plain http as well.
>
> > * The command with different Emacs version: 24.5, 26.3 and 28.0.50
> >   (trunk).
>
> Is your 24.5 Emacs linked against an older version of libgnutls?
> Otherwise I would expect it to have the same problem.
>

[-- Attachment #2: Type: text/html, Size: 3279 bytes --]

Re: GNU Elpa and Emacs 25.3

[Paul Pogonyshev]

[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]

Nevermind, found it. Guess it would have been easier if `libgnutls-version'
wasn't such a shady undocumented variable.

Paul

On Sat, 15 Feb 2020 at 22:05, Paul Pogonyshev <pogonyshev@gmail.com> wrote:

> Sorry to bother again, but now I run into a different problem with this. I
> set `gnutls-algorithm-priority' to "NORMAL:-VERS-TLS1.3" as suggested in
> that bugreport. This does work fine locally. However, when I use the same
> code on Travis CI for automated testing, I get the following error:
>
>      gnutls.c: [1] (Emacs) connecting to host: stable.melpa.org
>      gnutls.c: [1] (Emacs) allocating credentials
>      gnutls.c: [2] (Emacs) allocating x509 credentials
>      gnutls.c: [2] (Emacs) using default verification flags
>      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:-VERS-TLS1.3
>      gnutls.c: [1] (Emacs) setting the priority string
>      gnutls.c: [2] ASSERT: gnutls_priority.c:832
>
>      gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
> NORMAL:-VERS-TLS1.3 :hostname stable.melpa.org :loglevel 2
> :min-prime-bits 256 :trustfiles (/etc/ssl/certs/ca-certificates.crt)
> :crlfiles nil :keylist nil :verify-flags nil :verify-error nil :callbacks
> nil)
>      Package refresh done
>      Debugger entered--Lisp error: (gnutls-error #<process
> stable.melpa.org<1>> -50)
>        signal(gnutls-error (#<process stable.melpa.org<1>> -50))
>
> Travis CI (Ubuntu distribution Trusty) has an ancient GnuTLS version
> 2.12.6. As far as I understand, it doesn't know about TLS1.3 and therefore
> the attempt to disable it fails.
>
> Is there a way to use "NORMAL:-VERS-TLS1.3" in "do not fail" mode? Maybe I
> could somehow query if the library knows about 1.3 first?
>
> Paul
>
> On Sat, 25 Jan 2020 at 16:33, Noam Postavsky <npostavs@gmail.com> wrote:
>
>> On Sat, 25 Jan 2020 at 09:55, Paul Pogonyshev <pogonyshev@gmail.com>
>> wrote:
>> >
>> >     (file-error "https://elpa.gnu.org/packages/archive-contents" "Bad
>> Request")
>> >
>> > for me.  Also fails if I replace "https" with "http" in the command,
>> > though with a different error.
>>
>> The https failure is Bug#36749, though I'm surprised to hear that it
>> fails with plain http as well.
>>
>> > * The command with different Emacs version: 24.5, 26.3 and 28.0.50
>> >   (trunk).
>>
>> Is your 24.5 Emacs linked against an older version of libgnutls?
>> Otherwise I would expect it to have the same problem.
>>
>

[-- Attachment #2: Type: text/html, Size: 3895 bytes --]

Re: GNU Elpa and Emacs 25.3

[Noam Postavsky]

On Sun, 16 Feb 2020 at 07:52, Paul Pogonyshev <pogonyshev@gmail.com> wrote:
>
> Nevermind, found it. Guess it would have been easier if `libgnutls-version' wasn't such a shady undocumented variable.

Ah right, I had meant to fix that. Done now on emacs-27.

[1: af519a6348]: 2020-02-25 20:12:57 -0500
  Define libgnutls-version properly
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=af519a634878dd8e72f8276d82601b6562029107