Kevin Fenzi writes:
I personally don't see much advantage in expiring old keys or the like. The only attack vector I can see is tricking someone into installing a package from an EOL release with a known vulnerablity, but if you can do that you likely can get them to just download it and install it or download your resigned package and have them accept the key or any number of things.
I don't think much of expiring either. But keys for prior releases should simply be removed, as part of the upgrade process, or on the first boot after a successfull upgrade.
Now, if we go this way, we have to make sure we don't turn a bad situation into worse one. It's possible that a botched upgrade might end up with a system that's still bootable, so prior releases pgp keys should be left alone until it's known that fedup did its job successfully.
But once an upgrade is complete, prior release's pgp keys have absolutely no value in them, whatsoever, except as an additional potential compromise vector.
Attachment:
pgpJCrhKgma36.pgp
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
