Comment 7 for bug 1363482

> 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 debootstrap package so that it automatically picks the 'removed' keyring for Ubuntu <= 12.04 chroots on Ubuntu >= 17.04 hosts? The variable to do so already exists, the value just needs to be changed:

$ grep keyring /usr/share/debootstrap/scripts/precise
keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg

If this were updated to /usr/share/keyrings/ubuntu-archive-removed-keys.gpg it should work. This would avoid every single user of debootstrap having to work around this issue by themselves, like I've had to. This has affected at least some users (before me) already, as you can see by searching for the phrase "Release signed by unknown key (key id 40976EAF437D05B5)": https://www.google.com/search?q="Release+signed+by+unknown+key+%28key+id+40976EAF437D05B5%29"