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?
* 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 think that's what's being proposed to be fixed. rpm and/or yum should check.
I'm actually not sure I'm on board with that idea, though, because as you point out further down, the old releases are still served in mirrors, and could still be in use. I'm more concerned about following best practices to set expiration dates, so that a key cannot be used past a certain date to continue to sign new artifacts, unintentionally. Extremely long-lived keys increase the liklihood that they are using older generation algorithms which could be broken, weak algorithms, or simply due to their age they're old enough to have been brute-forced. I don't know that we should do anything on the verification or cleanup end of things, but setting an expiration date seems reasonable to me.
* 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.
One might argue that only geeks use Fedora or Linux in general, so I'm not sure that's much of a relevant point. The fact is GPG is used to sign RPMs, which are used by Fedora, so using GPG well is still relevant.
* 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 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 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.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
