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

@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.

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".