bug#35414: 26.2; ELPA packages signed with second, unknown key

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Brandon Invergo]

Hello,

I enabled package.el's signature-checking feature last night (variable
package-check-signature; Emacs 26.2).  I have imported the keyring at
etc/package-keyring.gpg, which contains one key:

pub   dsa2048 2014-09-24 [SC] [expires: 2019-09-23]
      CA442C00F91774F17F59D9B0474F05837FBDEF9B
uid           [ unknown] GNU ELPA Signing Agent <elpasign@elpa.gnu.org>

GNU ELPA is the only repository that has been enabled
(https://elpa.gnu.org/packages).

When I execute package-refresh-contents or when I try to install a
package from ELPA, it fails with the following error:

    Failed to verify signature archive-contents.sig:
    No public key for 066DAFCB81E42C40 created at 2019-04-24T10:15:06+0100 using RSA
    Good signature from 474F05837FBDEF9B GNU ELPA Signing Agent <elpasign@elpa.gnu.org> (trust undefined) created at 2019-04-24T10:15:06+0100 using DSA
    Command output:
    gpg: Signature made Wed 24 Apr 2019 10:15:06 AM BST
    gpg:                using DSA key CA442C00F91774F17F59D9B0474F05837FBDEF9B
    gpg: Good signature from "GNU ELPA Signing Agent <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: CA44 2C00 F917 74F1 7F59  D9B0 474F 0583 7FBD EF9B
    gpg: Signature made Wed 24 Apr 2019 10:15:06 AM BST
    gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
    gpg: Can't check signature: No public key

So, the signature by GNU ELPA Signing Agent (the key in
etc/package-keyring.gpg) is fine.  However, there is a second key
involved, for which the public key 066DAFCB81E42C40 is unavailable from
any public keyserver that I have tried.  Needless to say, it's not
available in etc/package-keyring.gpg either.  Since I do not have the
public key, the signature verification fails.

Just to be sure, I've also done it on a fresh installation-from-source
with an init.el that is empty apart from setting up package.el.  Same
results.

I have tried this from outside Emacs, by doing, for example:

    wget https://elpa.gnu.org/packages/delight-1.5.el{,.sig}
    gpg2 --verify delight-1.5.el.sig

This, of course, gives the same result as doing it from within Emacs.  I
mention it here to demonstrate that the problem is not in Emacs, from
what I can tell, but it is strictly due to this second, unknown key
signature.

For the extra paranoid, I've tried this on three different systems
residing on three different networks in two different countries.  I'm
pretty sure the problem is on the ELPA server and is a result of the
standard signing process.  However, we can't 100% rule out user
incompetence yet (my own, that is), so I am open to suggestions of what
else I might try to pin down the source of the problem.

Is the public key 066DAFCB81E42C40 available anywhere?  Or have I set up
something else incorrectly in the verification process?  Or is this
second signature there erroneously?

Thanks!

--
-brandon

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Glenn Morris]

Please forgive the top-posting.

I assume (without checking) that this is related to the key from
http://lists.gnu.org/r/emacs-diffs/2019-04/msg00546.html


Brandon Invergo wrote:

> I enabled package.el's signature-checking feature last night (variable
> package-check-signature; Emacs 26.2).  I have imported the keyring at
> etc/package-keyring.gpg, which contains one key:
>
> pub   dsa2048 2014-09-24 [SC] [expires: 2019-09-23]
>       CA442C00F91774F17F59D9B0474F05837FBDEF9B
> uid           [ unknown] GNU ELPA Signing Agent <elpasign@elpa.gnu.org>
>
> GNU ELPA is the only repository that has been enabled
> (https://elpa.gnu.org/packages).
>
> When I execute package-refresh-contents or when I try to install a
> package from ELPA, it fails with the following error:
>
>     Failed to verify signature archive-contents.sig:
>     No public key for 066DAFCB81E42C40 created at 2019-04-24T10:15:06+0100 using RSA
>     Good signature from 474F05837FBDEF9B GNU ELPA Signing Agent <elpasign@elpa.gnu.org> (trust undefined) created at 2019-04-24T10:15:06+0100 using DSA
>     Command output:
>     gpg: Signature made Wed 24 Apr 2019 10:15:06 AM BST
>     gpg:                using DSA key CA442C00F91774F17F59D9B0474F05837FBDEF9B
>     gpg: Good signature from "GNU ELPA Signing Agent <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: CA44 2C00 F917 74F1 7F59  D9B0 474F 0583 7FBD EF9B
>     gpg: Signature made Wed 24 Apr 2019 10:15:06 AM BST
>     gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
>     gpg: Can't check signature: No public key
>
> So, the signature by GNU ELPA Signing Agent (the key in
> etc/package-keyring.gpg) is fine.  However, there is a second key
> involved, for which the public key 066DAFCB81E42C40 is unavailable from
> any public keyserver that I have tried.  Needless to say, it's not
> available in etc/package-keyring.gpg either.  Since I do not have the
> public key, the signature verification fails.
>
> Just to be sure, I've also done it on a fresh installation-from-source
> with an init.el that is empty apart from setting up package.el.  Same
> results.
>
> I have tried this from outside Emacs, by doing, for example:
>
>     wget https://elpa.gnu.org/packages/delight-1.5.el{,.sig}
>     gpg2 --verify delight-1.5.el.sig
>
> This, of course, gives the same result as doing it from within Emacs.  I
> mention it here to demonstrate that the problem is not in Emacs, from
> what I can tell, but it is strictly due to this second, unknown key
> signature.
>
> For the extra paranoid, I've tried this on three different systems
> residing on three different networks in two different countries.  I'm
> pretty sure the problem is on the ELPA server and is a result of the
> standard signing process.  However, we can't 100% rule out user
> incompetence yet (my own, that is), so I am open to suggestions of what
> else I might try to pin down the source of the problem.
>
> Is the public key 066DAFCB81E42C40 available anywhere?  Or have I set up
> something else incorrectly in the verification process?  Or is this
> second signature there erroneously?

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Stefan Monnier]

> I assume (without checking) that this is related to the key from
> http://lists.gnu.org/r/emacs-diffs/2019-04/msg00546.html

Hmm... Indeed: this new keyring contains two keys (the old 2014 key
which will expire in September and a new key to replace it).

>> When I execute package-refresh-contents or when I try to install a
>> package from ELPA, it fails with the following error:
>>
>>     Failed to verify signature archive-contents.sig:
>>     No public key for 066DAFCB81E42C40 created at 2019-04-24T10:15:06+0100 using RSA
>>     Good signature from 474F05837FBDEF9B GNU ELPA Signing Agent <elpasign@elpa.gnu.org> (trust undefined) created at 2019-04-24T10:15:06+0100 using DSA
>>     Command output:
>>     gpg: Signature made Wed 24 Apr 2019 10:15:06 AM BST
>>     gpg:                using DSA key CA442C00F91774F17F59D9B0474F05837FBDEF9B
>>     gpg: Good signature from "GNU ELPA Signing Agent <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: CA44 2C00 F917 74F1 7F59  D9B0 474F 0583 7FBD EF9B
>>     gpg: Signature made Wed 24 Apr 2019 10:15:06 AM BST
>>     gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
>>     gpg: Can't check signature: No public key

Hmm... I just tried with Debian's Emacs-25.1 and with a new build from
the `emacs-26` branch:

    emacs -Q --eval '(setq package-check-signature t)
    M-x package-list-packages RET
    M-x package-refresh-contents RET

and didn't get any error.

>> So, the signature by GNU ELPA Signing Agent (the key in
>> etc/package-keyring.gpg) is fine.  However, there is a second key
>> involved, for which the public key 066DAFCB81E42C40 is unavailable from
>> any public keyserver that I have tried.

It's a brand new key that is now in etc/package-keyring.gpg in the
`master` branch of Emacs, as well as in the `gnu-elpa-keyring-update`
package in GNU ELPA.

This is because the key 474F05837FBDEF9B is about to expire (it's
really high time we start preparing for the new key).

>> Needless to say, it's not available in etc/package-keyring.gpg
>> either.  Since I do not have the public key, the signature
>> verification fails.

Yes, it's normal that the second signature can't be verified until you
install the new key, but that shouldn't cause an error in
package-install or package-refresh-contents.  At least that's what my
tests lead me to believe.


        Stefan

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Brandon Invergo]

Stefan Monnier writes:

>> I assume (without checking) that this is related to the key from
>> http://lists.gnu.org/r/emacs-diffs/2019-04/msg00546.html
>
> Hmm... Indeed: this new keyring contains two keys (the old 2014 key
> which will expire in September and a new key to replace it).

I see.  Sorry, I only searched the bugs list but not the diffs list!

> Hmm... I just tried with Debian's Emacs-25.1 and with a new build from
> the `emacs-26` branch:
>
>     emacs -Q --eval '(setq package-check-signature t)
>     M-x package-list-packages RET
>     M-x package-refresh-contents RET
>
> and didn't get any error.

I suppose it's worth asking (but apologies if I misunderstand what's
happening under the hood): did you perform this test with an empty
keyring (or just with what's available in Debian's Emacs-25.1
installation)?  I suspect that you already have the new public key in
your keyring, so you wouldn't experience the problem.

> It's a brand new key that is now in etc/package-keyring.gpg in the
> `master` branch of Emacs, as well as in the `gnu-elpa-keyring-update`
> package in GNU ELPA.
>
> This is because the key 474F05837FBDEF9B is about to expire (it's
> really high time we start preparing for the new key).

OK, that should make things easy enough.  Of course, I hadn't seen that
package because I was unable to update my archives!

Unfortunately, installing the package (after temporarily disabling sig
verification) doesn't solve the problem for me.  Am I correct to assume
that the package should "just work" after installing (and restarting
Emacs)?  Just for fun I tried manually running gnu-elpa-keyring-update,
which resulted in this this:

Debugger entered--Lisp error: (error "Can’t find the keyring.gpg file with the new keys")
  signal(error ("Can’t find the keyring.gpg file with the new keys"))
  error("Can't find the keyring.gpg file with the new keys")
  gnu-elpa-keyring-update--keyring()
  gnu-elpa-keyring-update()
  eval((gnu-elpa-keyring-update) nil)
  eval-expression((gnu-elpa-keyring-update) nil nil 127)
  funcall-interactively(eval-expression (gnu-elpa-keyring-update) nil nil 127)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)

gnu-elpa-keyring-update--keyring has the value
"etc/gnu-elpa-keyring.gpg", which doesn't exist relative to any relevant
paths that I can think of.  The files in .emacs.d/elpa/gnupg haven't
been modified.

I looked at the ELPA git repo and saw that the keyring should be
distributed in the etc subdirectory of the package.  So I tried manually
downloading the keyring from elpa.gnu.org via wget, however I got a 404
error (trying different reasonable URLs).  I then manually downloaded it
from the ELPA git repository and put it in
.emacs.d/elpa/gnu-elpa-keyring-update-2019.0/etc et voila!  Success.

So, I guess the "bug" at this point is that it would appear that the
keyring isn't properly installed with the keyring-update package.  I
apologize for the original noise, since you obviously had already
considered and worked on a fix for the underlying problem.

Thanks for your help!

--
-brandon

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Stefan Monnier]

> I see.  Sorry, I only searched the bugs list but not the diffs list!

No need to apologize: the new sigs appeared before the keyring
was distributed.

>> Hmm... I just tried with Debian's Emacs-25.1 and with a new build from
>> the `emacs-26` branch:
>>
>>     emacs -Q --eval '(setq package-check-signature t)
>>     M-x package-list-packages RET
>>     M-x package-refresh-contents RET
>>
>> and didn't get any error.
>
> I suppose it's worth asking (but apologies if I misunderstand what's
> happening under the hood): did you perform this test with an empty
> keyring (or just with what's available in Debian's Emacs-25.1
> installation)?

The keyring was not empty, but only had the 2014 key.

> I suspect that you already have the new public key in
> your keyring, so you wouldn't experience the problem.

I was also afraid of that, so I double checked.

>> It's a brand new key that is now in etc/package-keyring.gpg in the
>> `master` branch of Emacs, as well as in the `gnu-elpa-keyring-update`
>> package in GNU ELPA.
>>
>> This is because the key 474F05837FBDEF9B is about to expire (it's
>> really high time we start preparing for the new key).
>
> OK, that should make things easy enough.

But I don't want for people to have to update their keyring already:
they'll need to do that some time before September, but updating your
keyring will just hide the problem you're seeing.

> Unfortunately, installing the package (after temporarily disabling sig
> verification) doesn't solve the problem for me.  Am I correct to assume
> that the package should "just work" after installing (and restarting
> Emacs)?

Yes, even without restarting Emacs.

> I looked at the ELPA git repo and saw that the keyring should be
> distributed in the etc subdirectory of the package.

Oh, duh, of course, the scripts decided to make a single-file package
out of it, so the keyring is missing.  I'll fix that.

> So, I guess the "bug" at this point is that it would appear that the
> keyring isn't properly installed with the keyring-update package.  I
> apologize for the original noise, since you obviously had already
> considered and worked on a fix for the underlying problem.

No, the bug is that the signature verification should not signal an
error before September 2019 even if you don't have the new key.

Could you remove the gnu-elpa-keyring-update package, and the 2019
key from your keyring and try and help us figure out why you get
those errors and I don't?


        Stefan

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Stefan Monnier]

> No, the bug is that the signature verification should not signal an
> error before September 2019 even if you don't have the new key.
>
> Could you remove the gnu-elpa-keyring-update package, and the 2019
> key from your keyring and try and help us figure out why you get
> those errors and I don't?

Oh, wait, I see it now: I had set package-check-signature incorrectly.
So, I can reproduce the problem now with

    (setq package-check-signature t)
    
It works correctly if you've set it to the default `allow-unsigned`.

I think it's a mistake: `allow-unsigned` should mean to allow installing
packages when they don't have a signature at all, and `t` should mean
to allow installing if at least one of the sigs is verified rather than
only if all the sigs are verified.

But that ship has sailed, so I'm going to have to rethink the transition
to the new key.  Damn!


        Stefan

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Glenn Morris]

BTW I imagine 26f9a77 should be in the emacs-26 branch.
(Although no announcement has been made about the future of that
branch AFAIK.)

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 24 Apr 2019 19:07:31 -0400
> Cc: 35414@debbugs.gnu.org, Brandon Invergo <brandon@invergo.net>
> 
> 
> BTW I imagine 26f9a77 should be in the emacs-26 branch.

Fine with me, thanks.

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Stefan Monnier]

> BTW I imagine 26f9a77 should be in the emacs-26 branch.
> (Although no announcement has been made about the future of that
> branch AFAIK.)

I wasn't 100% sure that it was safe, so I wanted to give it some
exposure in `master` first.  But yes, I just pushed that change to
emacs-26.


        Stefan

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Brandon Invergo]

Stefan Monnier writes:

> But that ship has sailed, so I'm going to have to rethink the transition
> to the new key.  Damn!

At this point, it might just suffice to spread the word far and wide
that people using ELPA package verification need to 1) disable
verification, 2) install the transition package, and then 3) re-enable
verification.  A few well-placed announcements should directly reach a
substantial portion of ELPA users, while also potentially getting the
info indexed in search engines for more people to find when they get
affected.

All that said, I'm not an expert but an alternative strategy for the
future might be to extend the life of the original key (gpg --edit-key),
send it to a keyserver (gpg --send-keys), and then write an
"package-update-keyring" procedure that pulls updated public keys from
the keyserver (equivalent to gpg --recv-keys).  Of course, that doesn't
help the people who are not running the latest release that features the
update procedure, so a transitional package on ELPA that provides it
would still be necessary.

--
-brandon

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Stefan Kangas]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> No, the bug is that the signature verification should not signal an
>> error before September 2019 even if you don't have the new key.
>>
>> Could you remove the gnu-elpa-keyring-update package, and the 2019
>> key from your keyring and try and help us figure out why you get
>> those errors and I don't?
>
> Oh, wait, I see it now: I had set package-check-signature incorrectly.
> So, I can reproduce the problem now with
>
>     (setq package-check-signature t)
>
> It works correctly if you've set it to the default `allow-unsigned`.
>
> I think it's a mistake: `allow-unsigned` should mean to allow installing
> packages when they don't have a signature at all, and `t` should mean
> to allow installing if at least one of the sigs is verified rather than
> only if all the sigs are verified.
>
> But that ship has sailed, so I'm going to have to rethink the transition
> to the new key.  Damn!

What's the status on this?  Anything else that needs doing before 27.1?

Best regards,
Stefan Kangas

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Stefan Monnier]

> What's the status on this?  Anything else that needs doing before 27.1?

No, it's ready for 27.1.


        Stefan

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What's the status on this?  Anything else that needs doing before 27.1?
>
> No, it's ready for 27.1.

Is there anything more to do here, or should this bug be closed?

Best regards,
Stefan Kangas

bug#35414: 26.2; ELPA packages signed with second, unknown key

[Stefan Monnier]

> Is there anything more to do here, or should this bug be closed?

Done, thanks,


        Stefan