On 10/31/2017 01:08 PM, Christopher wrote: > > Why wouldn't the keys have expiration dates, following best practices? An > expired key is a bit friendlier of a nudge off of using outdated and > unsupported RPMs than a revoked key, which indicates a potential > compromise. I would expect any GPG keys for Fedora versions older than > EOL+5 or EOL+10 years to have already expired. Is that not the case? nope. It's not the case and it also largely doesn't matter. So, a few facts to toss on the thread: * All our keys that have been generated by sigul (which I think is all of them, the only exceptions used to be EPEL-4 and EPEL-5 which are both retired now) don't set expiration dates. * EPEL-5's key did have a 10 year expiration, and did expire early this year before it went end of life. Turns out the only thing that cared about that was sigul. yum doesn't check, rpm doesn't check, they happily keep using the expired key. * I've tried to sign the Fedora gpg keys in the past, but I'm really not sure it's worth it. IMHO gpg is kind of a dead end. It's hopelessly complex, no one bothers to use the web of trust as it was intended, it integrates very poorly with everything and only geeks use it. * Currently we don't do anything to make things difficult for EOL users. When a release goes EOL we archive it, but we continue to serve it in mirrormanager (now pointing to the archives) and we don't do anything with the keys. If we wish to do something like this, it should likely be a decision for FESCo and/or the Council. Changing this may annoy a large number of people. :) 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. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx