Failure getting compat on Emacs <29. seq.2.24 signature expired in gnu elpa?

Failure getting compat on Emacs <29. seq.2.24 signature expired in gnu elpa?

[Pierre Rouleau]

Hi,

I'm trying to install the compat package on a system running Emacs 26.3 but
it fails to verify the signature of seq-2.24
I used the package-list-packages and selected compat from gnu elpa.

On that Emacs, the `package-archives` is:

(("gnu" . "https://elpa.gnu.org/packages/")
 ("melpa" . "https://melpa.org/packages/")
 ("melpa-stable" . "https://stable.melpa.org/packages/")
 ("nongnu" . "https://elpa.nongnu.org/nongnu"))

When trying to install via the package-list-packages compat *Help* buffer
'install' button,
I get:

Failed to verify signature seq-2.24.tar.sig:
No public key for 645357D2883A0966 created at 2024-03-31T05:55:14-0400
using (unknown algorithm 22)
Signature made by expired key 066DAFCB81E42C40 GNU ELPA Signing Agent
(2019) <elpasign@elpa.gnu.org>
Command output:
gpg: Signature made Sun 31 Mar 05:55:14 2024 EDT
gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
gpg: Good signature from "GNU ELPA Signing Agent (2019) <
elpasign@elpa.gnu.org>" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: C433 5547 66D3 DDC6 4221  BFAA 066D AFCB 81E4 2C40
gpg: Signature made Sun 31 Mar 05:55:14 2024 EDT
gpg:                using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966
gpg: Can't check signature: No public key

Has someone submitted a signed package without publishing its public key or
is this something wrong on my end?

Any suggestions?

Thanks

-- 
/Pierre

Re: Failure getting compat on Emacs <29. seq.2.24 signature expired in gnu elpa?

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Failed to verify signature seq-2.24.tar.sig:
> No public key for 645357D2883A0966 created at 2024-03-31T05:55:14-0400
> using (unknown algorithm 22)
> Signature made by expired key 066DAFCB81E42C40 GNU ELPA Signing Agent
> (2019) <elpasign@elpa.gnu.org>
> Command output:
> gpg: Signature made Sun 31 Mar 05:55:14 2024 EDT
> gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
> gpg: Good signature from "GNU ELPA Signing Agent (2019) <
> elpasign@elpa.gnu.org>" [expired]
> gpg: Note: This key has expired!
> Primary key fingerprint: C433 5547 66D3 DDC6 4221  BFAA 066D AFCB 81E4 2C40
> gpg: Signature made Sun 31 Mar 05:55:14 2024 EDT
> gpg:                using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966
> gpg: Can't check signature: No public key
>
> Has someone submitted a signed package without publishing its public key or
> is this something wrong on my end?

You have the 2019 GNU ELPA signing key, but that one is expired.
(No)GNU ELPA packages are now signed with the 2022 key (distributed with
Emacs≥29 as well as in the `gnu-elpa-keyring-update` package).
The simplest is likely to install the `gnu-elpa-keyring-update` package,
but you may have to either disable signature checking temporarily,
or manually extent the lifetime of the 2019 key.


        Stefan

Re: Failure getting compat on Emacs <29. seq.2.24 signature expired in gnu elpa?

[Pierre Rouleau]

On Mon, Jun 3, 2024 at 12:59 AM Stefan Monnier via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:

>
> The simplest is likely to install the `gnu-elpa-keyring-update` package,
> but you may have to either disable signature checking temporarily,
> or manually extent the lifetime of the 2019 key.
>
Thanks for the info Stephan,

On that older system with Emacs 26.3 where the failure occurs,
I  tried to install the `gnu-elpa`keyring-update` package but that failed.
I tried with `package-check-signature'  set to allow-unsigned and
also tried with it set to nil.  In both case it failed with the following
message:

 Contacting host: elpa.gnu.org:443

Install package ‘gnu-elpa-keyring-update-2022.12’? (y or n) y
Contacting host: elpa.gnu.org:443
package-install-from-archive:
https://elpa.gnu.org/packages/gnu-elpa-keyring-update-2022.12.tar: Not found

How would I extend the lifetime of the 2019 key?
This occurs on an old system, kept old on purpose for testing,
a macOS Mojave system where installing software is often a challenge.

If all else fail, I have other systems where all is fine and have downloaded
the package.  Could I just copy the files and install it manually?
Aside from copying the files inside the ~/.emacs.d/elpa directory, what
else must be done?

-- 
/Pierre

Re: Failure getting compat on Emacs <29. seq.2.24 signature expired in gnu elpa?

[Pierre Rouleau]

On Mon, Jun 3, 2024 at 8:02 AM Micha Silver <tsvibar@gmail.com> wrote:

>
> On 03/06/2024 14:55, Pierre Rouleau wrote:
> > On Mon, Jun 3, 2024 at 12:59 AM Stefan Monnier via Users list for the GNU
> > Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
> >
> > On that older system with Emacs 26.3 where the failure occurs,
> > I  tried to install the `gnu-elpa`keyring-update` package but that
> failed.
> > I tried with `package-check-signature'  set to allow-unsigned and
> > also tried with it set to nil.  In both case it failed with the following
> > message:
> >
> >   Contacting host: elpa.gnu.org:443
> >
> > Install package ‘gnu-elpa-keyring-update-2022.12’? (y or n) y
> > Contacting host: elpa.gnu.org:443
> > package-install-from-archive:
> > https://elpa.gnu.org/packages/gnu-elpa-keyring-update-2022.12.tar: Not
> found
> >
> > How would I extend the lifetime of the 2019 key?
>
>
> (total newbie here) I downloaded the 2022 package manually, then ran
>
> M-x package-install-file
>
> Thanks Micha for reminding me about the package-install-file!

Installing the file using (package-install-file
"gnu-elpa-keyring-update-pkg.el")
does create the elpa directory with the  .el fles and byte-compiles it but
it does
not place the etc sub-directory and does not create the
gnu-elpa-keyring-update-2022.12.1.signed file in the elpa directory.
- To handle the etc directory, I just copied it
- As far as the missing gnu-elpa-keyring-update-2022.12.1.signed file I
tried without it
  and then tried with a copy of that file.

The problem with gnu elpa was solved.  However I still had a http 404
problem if nongnu,
 ("nongnu" . "https://elpa.nongnu.org/nongnu") ,
was included inside the the `package-archives`:
  with  `M-x package-list-packages`

error in process filter: Error retrieving:
https://elpa.nongnu.org/nongnuarchive-contents (error http 404)

The *problem was the missing trailing slash in the URL string*!

The problem was inside my init.el file.

Would it make sense to include a function that would add cons cells in
package-archives and would check for missing trailing slash?
That function could also deal with various issues that occurred over time
like the one for emacs 26.1 and 26.2 having to set
gnutls-algorithm-priority?

Thanks Stephan & Micha!

-- 
/Pierre

Re: Failure getting compat on Emacs <29. seq.2.24 signature expired in gnu elpa?

[Robert Pluim]

>>>>> On Mon, 3 Jun 2024 09:38:50 -0400, Pierre Rouleau <prouleau001@gmail.com> said:
    Pierre> error in process filter: Error retrieving:
    Pierre> https://elpa.nongnu.org/nongnuarchive-contents (error http 404)

    Pierre> The *problem was the missing trailing slash in the URL string*!

    Pierre> The problem was inside my init.el file.

    Pierre> Would it make sense to include a function that would add cons cells in
    Pierre> package-archives and would check for missing trailing slash?
    Pierre> That function could also deal with various issues that occurred over time
    Pierre> like the one for emacs 26.1 and 26.2 having to set
    Pierre> gnutls-algorithm-priority?

emacs-29 already adds a '/' on the end if itʼs missing.

Robert
-- 

Re: Failure getting compat on Emacs <29. seq.2.24 signature expired in gnu elpa?

[Pierre Rouleau]

On Mon, Jun 3, 2024 at 9:54 AM Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Mon, 3 Jun 2024 09:38:50 -0400, Pierre Rouleau <
> prouleau001@gmail.com> said:
>     Pierre> error in process filter: Error retrieving:
>     Pierre> https://elpa.nongnu.org/nongnuarchive-contents (error http
> 404)
>
>     Pierre> The *problem was the missing trailing slash in the URL string*!
>
>     Pierre> The problem was inside my init.el file.
>
>     Pierre> Would it make sense to include a function that would add cons
> cells in
>     Pierre> package-archives and would check for missing trailing slash?
>     Pierre> That function could also deal with various issues that
> occurred over time
>     Pierre> like the one for emacs 26.1 and 26.2 having to set
>     Pierre> gnutls-algorithm-priority?
>
> emacs-29 already adds a '/' on the end if itʼs missing.
>
> Robert
> --
>
Good to know, thanks Robert!

-- 
/Pierre

Re: Failure getting compat on Emacs <29. seq.2.24 signature expired in gnu elpa?

[Stefan Monnier]

> Install package ‘gnu-elpa-keyring-update-2022.12’? (y or n) y
> Contacting host: elpa.gnu.org:443
> package-install-from-archive:
> https://elpa.gnu.org/packages/gnu-elpa-keyring-update-2022.12.tar: Not found

Presumably your Emacs used an old cached version of `archive-contents`
(the current version is 2022.12.1).


        Stefan

Re: Failure getting compat on Emacs <29. seq.2.24 signature expired in gnu elpa?

[Pierre Rouleau]

On Mon, Jun 3, 2024 at 10:48 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > Install package ‘gnu-elpa-keyring-update-2022.12’? (y or n) y
> > Contacting host: elpa.gnu.org:443
> > package-install-from-archive:
> > https://elpa.gnu.org/packages/gnu-elpa-keyring-update-2022.12.tar: Not
> found
>
> Presumably your Emacs used an old cached version of `archive-contents`
> (the current version is 2022.12.1).
>
> It's quite possible.  As I said that specific system runs macOS Mojave,
which is no longer supported by Apple.  Installing software on it is a
challenge,
except for Emacs lisp packages, or something I can get through DVCS like
Git,
Mercurial, etc and build from source.

But I ran into another issue on that system once accessing gnu and nongnu
was solved.
I tried to install the emacs-eat from nongnu elpa and got the following
error:

Failed to verify signature eat-0.9.4.tar.sig:
Good signature from 645357D2883A0966 GNU ELPA Signing Agent (2023) <
elpasign@elpa.gnu.org> (trust undefined) created at
2024-03-31T07:10:08-0400 using (unknown algorithm 22)
Signature made by expired key 066DAFCB81E42C40 GNU ELPA Signing Agent
(2019) <elpasign@elpa.gnu.org>
Command output:
gpg: Signature made Sun 31 Mar 07:10:08 2024 EDT
gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
gpg: Good signature from "GNU ELPA Signing Agent (2019) <
elpasign@elpa.gnu.org>" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: C433 5547 66D3 DDC6 4221  BFAA 066D AFCB 81E4 2C40
gpg: Signature made Sun 31 Mar 07:10:08 2024 EDT
gpg:                using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966
gpg: Good signature from "GNU ELPA Signing Agent (2023) <
elpasign@elpa.gnu.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the
owner.
Primary key fingerprint: AC49 B8A5 FDED 6931 F40E  E78B F993 C037 86DE 7ECA
     Subkey fingerprint: 0327 BE68 D64D 9A1A 6685  9F15 6453 57D2 883A 0966

It's probably something invalid on that system, which runs Emcas 26.3.
I have been able to install the eat package on other systems that run
Emacs 27.2 or 29.3 without any problem.

My knowledge of gpg is not what I'd like it to be...
Is there something obvious I should do on that old system to solve the
above problem?

Thanks

-- 
/Pierre

Re: Failure getting compat on Emacs <29. seq.2.24 signature expired in gnu elpa?

[Stefan Monnier]

> It's probably something invalid on that system, which runs Emcas 26.3.
> I have been able to install the eat package on other systems that run
> Emacs 27.2 or 29.3 without any problem.

That rings a bell... oh yes, here it is in NEWS.27:

    *** Change of 'package-check-signature' for packages with multiple sigs.
    In previous Emacsen, t checked that all signatures are valid.
    Now t only checks that at least one signature is valid and the new 'all'
    value needs to be used if you want to enforce that all signatures
    are valid.  This only affects packages with multiple signatures.

🙁


        Stefan