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

[Dan McGee]

On Sun, Apr 24, 2011 at 8:25 AM, Allan McRae <allan at archlinux.org> wrote:
> 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.
Well sure...that was my point and what I gathered though- if you have
a keyring that has keys you only trust, you don't need a trust DB, no?

http://www.debian.org/doc/manuals/securing-debian-howto/ch7

Debian does not provide signed packages but provides a mechanism
available since Debian 4.0 (codename etch) to check for downloaded
package's integrity[52]. For more information, see Secure apt, Section
7.5.2.

http://www.debian.org/doc/manuals/securing-debian-howto/ch7#s-apt-0.6

gpg is the tool used in secure apt to sign files and check their signatures.

apt-key is a program that is used to manage a keyring of gpg keys for
secure apt. The keyring is kept in the file /etc/apt/trusted.gpg (not
to be confused with the related but not very interesting
/etc/apt/trustdb.gpg). apt-key can be used to show the keys in the
keyring, and to add or remove a key.

> 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.
Yes, totally understand. However, it only creates said lock file IF a
trustdb has content

> 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.
This sounds scary and not good at all to me...

> 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.