Urgent matter with GNU ELPA keys

Urgent matter with GNU ELPA keys

[Stefan Monnier]

I just saw that the GNU ELPA signing key that we distribute with Emacs
(stored in etc/package-keyring.gpg) will expire in September.

It's easy to change elpa.gnu.org to sign with a new key, but the hard
part that we need to take care of ASAP is to figure out how we're going
to let users of already-distributed Emacsen access GNU ELPA when that
new key is used.

My GPG-fu is rather weak, so I need help,


        Stefan

Re: Urgent matter with GNU ELPA keys

[Andreas Schwab]

On Feb 11 2019, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I just saw that the GNU ELPA signing key that we distribute with Emacs
> (stored in etc/package-keyring.gpg) will expire in September.
>
> It's easy to change elpa.gnu.org to sign with a new key, but the hard
> part that we need to take care of ASAP is to figure out how we're going
> to let users of already-distributed Emacsen access GNU ELPA when that
> new key is used.
>
> My GPG-fu is rather weak, so I need help,

You can edit a key to extend its expiration date (if you have the secret
key, of course).

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Urgent matter with GNU ELPA keys

[Amin Bandali]

On 2019-02-11  4:27 PM, Andreas Schwab wrote:

[...]

> You can edit a key to extend its expiration date (if you have the secret
> key, of course).
>

Indeed.  One would do `gpg --edit-key <keyid>', then use `expire' to set
the expiry of the main key.  If there are any subkeys (which I don’t
think is the case here, but anyway), one can toggle their selection
using the `key <number>' command where <number> is the 1-based index of
the order in which the subkey appears.

If I understand correctly, package.el imports the key(s) from the
etc/package-keyring.gpg file shipped with Emacs as you mentioned.  So
the first step would indeed be updating that file to ship the key with
the extended expiry date for future releases.  As for users of current
versions, however, I’m not sure what would be the best way to proceed.
For users of current versions, at some point they would have to re-fetch
the key to have its expiry date updated.  We could instruct them to do
so by invoking gpg with the right options (for settings the correct gpg
home directory and the right keyring), but I’m guessing that would
require root access in most cases (since the shipped keyring file would
likely have been installed by a system package manager in a location
that cannot be written to by regular users)?

For future versions, though, I wonder if it’d be a good idea to add a
function in package.el to aid with re-fetching the key.  Though even
then we’d still have to think about the root access requirement issue
for updating the shipped keyring.

Re: Urgent matter with GNU ELPA keys

[Phillip Lord]

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

> I just saw that the GNU ELPA signing key that we distribute with Emacs
> (stored in etc/package-keyring.gpg) will expire in September.
>
> It's easy to change elpa.gnu.org to sign with a new key, but the hard
> part that we need to take care of ASAP is to figure out how we're going
> to let users of already-distributed Emacsen access GNU ELPA when that
> new key is used.
>
> My GPG-fu is rather weak, so I need help,


Write a package called "package-keys.el" which includes the new
key. Sign it with the existing key distributed with Emacs.

Of course, this will have what you might call a reverse bootstrap
problem -- users will need to install package-keys.el before they key
runs out, but they won't know that they need to do this till the key
runs out. After this, Emacs will refuse to install the package that it
needs to allow the installation. Only solution I can see here would be
to put some code that people can eval in *scratch* that bypasses the key
signing thing.

Long term solution would be an auto-updating and installing version of
package-keys.el and maybe package.el. This would have practical problems
(because ELPA doesn't support multiple versions of packages). I expect
Richard would object also.

Phil