Working with a system-shared keyring

Dan McGee dpmcgee at gmail.com
Fri Jun 3 17:10:15 CEST 2011


On Fri, Jun 3, 2011 at 2:19 AM, Werner Koch <wk at gnupg.org> wrote:
> On Thu,  2 Jun 2011 00:41, dpmcgee at gmail.com said:
>
>> 1. Does anyone else have experience with a shared among users keyring?
>
> Be warned that future gpg versions may not support the use of multiple
> keyrings.  It is not easy to define the semantics for this as it is
> similar to a translucent filesystem.

Perhaps I phrased this bad- I more meant "accessible to multiple
users". When using this keyring, no other keyring will ever come into
play, as $GNUPGHOME is set to this shared directory
(/etc/pacman.d/gnupg/).

>> 2. What is best/secure practice when it comes to this? Outside of
>> --lock-never, yum does something that seems silly, but works- make a
>> user-owned copy of the entire keyring directory and then uses that.
>
> Importing all the keys is the safest strategy.
Importing to where, and trust levels as well? The idea here is we are
using this keyring for one purpose only- the system-defined keyring
and trust levels used to verify downloaded and to-be-installed
packages and metadata. Having user-specific keyrings/trustdbs for this
stuff doesn't seem to make much sense unless I'm overlooking
something.

> Disable locking for a shared resource requires at least to check that no
> write bits are set for the file.  I am not sure whetehr such checks are
> justified given the above mentioned problems with shared keyrings.
>
>
>> 3. gpgme doesn't allow us to bypass the trustdb.gpg locking; is there
>> any possibility of allowing gpgme to run with --lock-never in a
>> read-only mode?
>
> You may specify a different home directory with gpgme and in that
> home directory you put the option lock-never into gpg.conf.
Aha, didn't think about this, but it makes sense- thanks. Of course if
the user that does have write permissions on these files (root) runs
gpg, then the --lock-never would be unwanted but maybe we have to live
with that.

>  You can change the configuration of a backend engine, and thus change
>  the executable program and configuration directory to be used.  You can
>  make these changes the default or set them for some contexts
>  individually.
>
>   -- Function: gpgme_error_t gpgme_set_engine_info
Yes, we are doing this already and are setting the home directory to
/etc/pacman.d/gnupg/.

-Dan



More information about the Gnupg-users mailing list