Code review comment for lp://qastaging/~smoser/vmbuilder/mfdiff-apt-key-transition

On 9 January 2017 at 18:52, Scott Moser <email address hidden> wrote:
> @Dimitri,
> I'm confused.
>
> "everything should be dual-signed, and just one valid trusted signature should be sufficient (aka just the /usr/share/keyrings/ubuntu-archive-keyring.gpg)"
>
> I didn't make up this problem. I'm pretty sure that everything is *not* dual-signed... thats the point of the transition, otherwise it wouldn't be a 'transition'.
>
> The problem is specifically that if you run mfdiff on zesty, then the python-apt code (or something in that path) downloads apt data, and checks it, but the apt data it downloads is signed with a key that is not in /usr/share/keyrings/ubuntu-archive-keyring.gpg . It is downloading xenial archive data on a zesty system and the zesty key ring does not have the xenial signer.
>

python-apt nor apt itself use
/usr/share/keyrings/ubuntu-archive-kerying.gpg by default

by default they use /etc/apt/trusted.gpg.d/* fragments and legacy
/etc/apt/trusted.gpg only

looking at the code, i'm struggling to see what exactly errors out.
What keys are installed in the cacheroot? doesn't everything read the
trusted keys not from the host, but from the cacheroot... which has no
keys at all? shouldn't trusted-keys be pointed to the host, rather
than cacheroot?

note python-apt has changed in zesty. Can you try to install e.g.
ubuntu-kerying from zesty on a xenial system; and check if this script
works or not?

> I wonder, what is the plan for a compromise on an archive signing key? Would that key then get moved into ubuntu-archive-removed-keys.gpg ? or would it be added to a ubuntu-archive-COMPROMISED-keys.gpg ? The reason I ask is that if we added it to -removed-keys.gpg, then anyone using that (as you suggest above) would be open to MIM attack.
>
> I do admit that checking these keys in directly here as I've suggested in this MP *does* open me up to a MIM attack on someone who has gained access to the old archive key, and it does seem like there should be some path forward that would allow me to trust "old keys that are not known to be compromised".
>

Even when the key is compromised we will continue to sign the archives
with the compromised key in addition to the newly generated key, as
otherwise it will break fresh installs with last point release media.
(I'm guessing if key is ever compromised we will be doing installation
media respin trusting new keys only).

There should be valid signatures for one or more keys one trusts, so a
valid signature with the 4k key and a signature for a missing key
should be still ok. The signature with a missing key might be a newly
generated key; or an obsoleted key; one can never know.

--
Regards,

Dimitri.