[pacman-dev] trustdb locking issues and snippets from the apt changelog

[Allan McRae]

On 23/04/11 09:32, Dan McGee wrote:
> Allan and I today, and Denis in the past, noticed some issues with
> having a shared public key database and locking that gpg wants to do
> when reading from it. Here is an interesting bit from the apt
> changelog:
>
> apt (0.6.2) experimental; urgency=low
>    * Provide apt-key with a secret keyring and a trustdb, even though we
>      would never use them, because it blows up if it doesn't have them
>
>> From what I gather, they don't use the trustdb for the reasons we are
> seeing; instead it looks like they have another keyring named
> "trusted.gpg" and go forth with the assumption that everything in
> there is to be trusted.
>

Looking into this, I believe that we are hitting an entirely separate 
issue.  The reason for a lack of trustdb in the Debian case appears to 
be more to do with keyring management that anything else.

The main issue here is that gpg(me) creates a lock file in the keyrings 
home directory whenever it uses a keyring.  Our keyring directory only 
has write permissions for the root user and thus when pacman is not 
being run as root (such as the "pacman -Qip <pkg>" case), it can not 
create a lock file.

We can work around this by making the /etc/pacman.d/gnupg directory have 
777 permissions.  The {pubring,secring,trustdb},gpg files will
still have only root write permissions so I guess this is safe as long 
as those files are created as part of the pacman package itself... 
Also, unless I am missing something even if other files are added in 
that directory by a user, they should not affect gpg.  Still... 777 
permissions on that directory sounds scary.

Anyway, doing this makes the signature validation with -Qip work for 
non-root users (using Dan's gpg branch WIP patches).

Note that GPG itself has an option not to do locking (with a big warning 
about that being bad...), and I thought maybe we could do that for the 
non-root usage case, but it looks like gpgme can not do that.

Allan