Working with a system-shared keyring
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
>> 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
> 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
> -- 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