GNU bug report logs - #35414
26.2; ELPA packages signed with second, unknown key

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Brandon Invergo <brandon <at> invergo.net>
Subject: bug#35414: closed (Re: bug#35414: 26.2; ELPA packages signed with
 second, unknown key)
Date: Sat, 25 Jan 2020 17:32:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 35414 <at> debbugs.gnu.org.

-- 
35414: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=35414
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 35414-done <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>,
 Brandon Invergo <brandon <at> invergo.net>
Subject: Re: bug#35414: 26.2; ELPA packages signed with second, unknown key
Date: Sat, 25 Jan 2020 12:31:21 -0500

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

Done, thanks,


        Stefan

[Message part 3 (message/rfc822, inline)]

From: Brandon Invergo <brandon <at> invergo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.2; ELPA packages signed with second, unknown key
Date: Wed, 24 Apr 2019 13:56:00 +0100

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 <at> 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 <at> 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 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.