On Tue, Oct 31, 2017 at 3:06 PM David Cantrell <dcantr...@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
