On 11/01/2017 01:07 PM, Christopher wrote:
On Wed, Nov 1, 2017 at 3:26 PM Kevin Fenzi <kevin(a)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