On 11/01/2017 01:07 PM, Christopher wrote:
> On Wed, Nov 1, 2017 at 3:26 PM Kevin Fenzi <ke...@scrye.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to