On 11/01/2017 01:07 PM, Christopher wrote: > On Wed, Nov 1, 2017 at 3:26 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > >> 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. >> >> > Is it possible to change that behavior? Sure. Would require an RFE against sigul and code/work to implement, but it should be possible. ...snip... > I think setting EOL+10 year expiration date would probably annoy nobody if > the verification simply produced a warning about age and didn't actually > cause anything to fail. I think going to all the work of implementing that would waste a lot of peoples time and cause EOL using people to change nothing. > > >> 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. >> >> > Yeah, that's the attack vector I was thinking. It's also the case that > somebody could be tricked into installing an older version of a patched > package from the current release, which is signed by the same GPG key. So, > maybe it's not much of a mitigation of anything. Still, I think adding a > reasonable expiration date is good practice... and warning during > verification (or making a verification policy configurable in yum/dnf) > might be a good idea. Well, feel free to file RFE's on yum/rpm/dnf, but I suspect they have lots of more important things to implement. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
