ubuntu-keyring includes 1024D keys

[Philipp Kern]

ubuntu-keyring as shipped in trusty contains old 1024D keys dating back to 2004 which are still being trusted for the main archive:

 % gpg /usr/share/keyrings/ubuntu-archive-keyring.gpg | grep 1024D
pub 1024D/437D05B5 2004-09-12 Ubuntu Archive Automatic Signing Key <email address hidden>
pub 1024D/FBB75451 2004-12-30 Ubuntu CD Image Automatic Signing Key <email address hidden>

Given that newer 4096R keys are present and have been in precise (through -updates) and trusty, it seems to be about time to drop the older keys. (In the hope that apt does not chose on signatures it cannot verify, otherwise the publisher would need to stop signing with the old key as well.)

[Marc Deslauriers (mdeslaur)]

Precise archive is only signed with the old key. To support using the precise archive in newer releases, such as with debootstrap, we need to do the following:

1- Make sure Precise's apt supports a double-signed release file
2- Start double-signing the Precise archive
3- Double-sign old ISO *SUMS files

We can then drop the old key in the dev release and in an update to stable releases.

[Adam Conrad (adconrad)]

Adding an ubuntu-cdimage task to make it support double-signing, so I can go back and alter history.

[Colin Watson (cjwatson)]

I've added double-signing support to cdimage, and re-signed everything with both old and new keys. For good measure I've also updated https://help.ubuntu.com/community/VerifyIsoHowto.

[Marc Deslauriers (mdeslaur)]

Adam,

Any progress on getting the precise archive signed with the newer keys?

[Dimitri John Ledkov (xnox)]

Might as well just wait for precise EOL.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-keyring - 2016.10.27

---------------
ubuntu-keyring (2016.10.27) zesty; urgency=medium

  * Drop 1024D key fragments. LP: #1363482
  * Remove 1024D keys from ubuntu-archive-keyring.
  * Add 1024D keys to ubuntu-archive-removed-keys.gpg.
  * Remove the md5sums.asc file, no longer valid.
  * Regenerate SHA512SUMS.txt.asc file.

 -- Dimitri John Ledkov <email address hidden> Thu, 27 Oct 2016 15:31:35 +0100

[Peter Odding (peterodding)]

> Precise archive is only signed with the old key. To support using the precise archive in newer releases, such as with debootstrap, we need to do the following ...

This comment implied to me that the use of debootstrap to create an Ubuntu 12.04 chroot on e.g. Ubuntu 18.04 (which includes the ubuntu-keyring package update discussed here) should work, however I recently found out that it doesn't:

$ sudo debootstrap precise /tmp/precise http://old-releases.ubuntu.com/ubuntu/
I: Retrieving InRelease
I: Retrieving Release
I: Checking Release signature
E: Release signed by unknown key (key id 40976EAF437D05B5)

At this point debootstrap exits with status code 1. My use case is based on a Python package (maintained by me) that automates the creation of Debian and Ubuntu chroots by discovering and ranking available mirrors, automatically picking a good mirror and then running debootstrap with the appropriate command line options. Based on this Launchpad issue I realized that I needed to use 'ubuntu-archive-removed-keys.gpg' and indeed then things work as expected:

$ sudo debootstrap --keyring=/usr/share/keyrings/ubuntu-archive-removed-keys.gpg precise /tmp/precise http://old-releases.ubuntu.com/ubuntu/
I: Retrieving InRelease
I: Retrieving Release
I: Checking Release signature
I: Valid Release signature (key id 630239CC130E1A7FD81A27B140976EAF437D05B5)
I: Validating Packages
I: Resolving dependencies of required packages...

The tricky thing for me was that my Python package needs to decide this for the user, since it abstracts away the call to debootstrap, so I needed an exact understanding of the situation (the terseness of this Launchpad issue wasn't explicit enough for me, given a lack of knowledge about Ubuntu internals). I created the following overview of Ubuntu signing keys to help me understand the situation:

warty: 0x40976EAF437D05B5
hoary: 0x40976EAF437D05B5
breezy: 0x40976EAF437D05B5
dapper: 0x40976EAF437D05B5
edgy: 0x40976EAF437D05B5
feisty: 0x40976EAF437D05B5
gutsy: 0x40976EAF437D05B5
hardy: 0x40976EAF437D05B5
intrepid: 0x40976EAF437D05B5
jaunty: 0x40976EAF437D05B5
karmic: 0x40976EAF437D05B5
lucid: 0x40976EAF437D05B5
maverick: 0x40976EAF437D05B5
natty: 0x40976EAF437D05B5
oneiric: 0x40976EAF437D05B5
precise: 0x40976EAF437D05B5
quantal: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32
raring: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32
saucy: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32
trusty: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32
utopic: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32
vivid: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32
wily: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32
xenial: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32
yakkety: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32
zesty: 0x3B4FE6ACC0B21F32
artful: 0x3B4FE6ACC0B21F32
bionic: 0x3B4FE6ACC0B21F32
cosmic: 0x3B4FE6ACC0B21F32

The issue that I created to track this issue "on my side" contains a lot more details (including the script that was used to create the overview of signing keys) and is available here: https://github.com/xolox/python-apt-mirror-updater/issues/8

Now that I've implemented a workaround for this issue it's no longer very pressing for me, however wouldn't it be prudent to update the deboots...

[Peter Odding (peterodding)]

Going over my notes on this topic I realized that I hadn't pointed out in my previous message that the issue I've pointed out has already triggered a workaround (that shouldn't be necessary IMHO) in the pbuilder project:

https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/599394

In my opinion neither pbuilder nor apt-mirror-updater should be implementing workarounds for this issue, because there's lots more use cases for debootstrap than just these two projects, and each will require a workaround until my suggested change to debootstrap is implemented.

[Peter Odding (peterodding)]

It's a shame I can't edit comments on Launchpad: Please disregard my last comment, I seem to have misread the pbuilder issue, sorry for the noise. That doesn't change the validity of my point about updating debootstrap though.