Working with a system-shared keyring

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

On Fri, Jun 3, 2011 at 2:19 AM, Werner Koch <wk at> wrote:
> On Thu,  2 Jun 2011 00:41, dpmcgee at 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

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

> 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


More information about the Gnupg-users mailing list