[Rpm-maint] gpg checking packages and gpg pub key storage

[Panu Matilainen]

On Fri, 22 Jun 2007, seth vidal wrote:

> Hi all,
> It seems like a trend recently in my conversations that questions come
> up about signature checking rpm packages. Specifically why we need to
> have the rpmdb open in order to do it. At some point in the mists of
> time the move was made from storing gpg pub keys in a gpg keyring to
> storing them in the rpmdb. So in order to get to the key or to open an
> rpm, at all, you have to have a transaction set available and,
> implicitly, an rpmdb open to get to the keys.
>
> What I'm wondering is if it might be time in future development branches
> to revert that change? Here's what I was thinking:
>
> 1. gpg keys get pulled back out an stored in some location that can be
> safely written to by a process (not /root/.gnupg :) We have lots of
> library interfaces to gpg these days and this would keep the confusion
> down about whether or not a gpg pubkey is a package. :)
>
> 2. try to determine a better way to access a package header and other
> information that doesn't involve having a transaction set open.
>
> Essentially, I'm trying to get away from everything having to have an
> rpmdb, of some kind, open.

I don't disagree, but there are two distinct issues here which 
shouldn't be mixed up:
a) the handling and implementation of gpg keys within rpm
b) the horrors of rpmdb locking

There's no shortage of "can't import <somebody>'s gpg key into rpmdb" and 
related issues in current rpm. If you apply traditional unix philosophy of 
software doing one thing and doing that thing well, rpm shouldn't try to 
play a gpg key manager.

The locking stuff.. ick. Updating the internal BDB to a newer version that 
has methods to support automatic stale lock removal should help quite a 
bit. But on the whole, the rpmdb locking scheme is something we might want 
to rethink from the ground up to see if there isn't some nicer way to do 
it all.

 	- Panu -