unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Brandon Invergo <brandon@invergo.net>
To: 35414@debbugs.gnu.org
Subject: bug#35414: 26.2; ELPA packages signed with second, unknown key
Date: Wed, 24 Apr 2019 13:56:00 +0100	[thread overview]
Message-ID: <87mukfsgtb.fsf@invergo.net> (raw)

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





             reply	other threads:[~2019-04-24 12:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-24 12:56 Brandon Invergo [this message]
2019-04-24 16:08 ` bug#35414: 26.2; ELPA packages signed with second, unknown key Glenn Morris
2019-04-24 19:36   ` Stefan Monnier
2019-04-24 22:03     ` Brandon Invergo
2019-04-24 22:36       ` Stefan Monnier
2019-04-24 23:02         ` Stefan Monnier
2019-04-24 23:07           ` Glenn Morris
2019-04-25  6:23             ` Eli Zaretskii
2019-05-08 17:20             ` Stefan Monnier
2019-04-25  8:36           ` Brandon Invergo
2019-09-30 22:02 ` Stefan Kangas
2019-09-30 23:27   ` Stefan Monnier
2020-01-25 17:12     ` Stefan Kangas
2020-01-25 17:31       ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mukfsgtb.fsf@invergo.net \
    --to=brandon@invergo.net \
    --cc=35414@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).