On 10/31/2017 04:08 PM, Christopher wrote: > On Tue, Oct 31, 2017 at 3:06 PM David Cantrell <dcantrell@xxxxxxxxxx > <mailto: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? I don't know if the keys have expiration dates or not, but that would be effective too. And our packaging tools could clean things up based on that information as well. -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
