On Tue, Oct 31, 2017 at 3:06 PM David Cantrell <dcantrell@xxxxxxxxxx> wrote:
On 10/31/2017 11:32 AM, R P Herrold wrote:
> On Tue, 31 Oct 2017, David Cantrell wrote:
>
>>> # rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"|wc -l
>>> 64
>>
>> Do we issue revocations for old keys? If not, let's do that and extend
>> dnf to honor those and clean up?
>
> What is the 'use case' for potentially preventing installation
> against a already know key of a existing, but older 'noarch'
> package; or one unpacking an older SRPM and NOT getting the
> scary NOKEY warning? The size of the keys is trivial, even
> though they do tend to accrete in a 'long running' instance
>
> heck, I'll wager mostly those keys are never countersigned
> into a web of trust, and sent to the constellation of GnuPG
> key-servers in the first place
>
> Going even further, and revoking the keys is 'fly-specking'
> overkill
>
> I have no problem with removing keys not _used_ on a given
> host (such information being able to be compiled out of the
> RPM database)
I don't really consider this a thing about saving space or making the
output of 'rpm -qa' look nicer or something, but rather being good users
of GPG. If we create and then phase out signing keys, then part of our
process should also involve sending revocations for the old keys. And
that process could be automated by a dnf plugin too. Leaving old keys
around on the system for verification purposes presents a risk should
the old key become compromised.
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?
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
