Working with a system-shared keyring

[Werner Koch]

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.

What we currently do is to write changes to the first writable keyring.
This may lead to a situation were we have 2 copies of the keys; one
updated and one not updated.

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

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.

  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
            (gpgme_protocol_t PROTO, const char *FILE_NAME,
            const char *HOME_DIR)
       The function `gpgme_set_engine_info' changes the default
       configuration of the crypto engine implementing the protocol PROTO.
  
       FILE_NAME is the file name of the executable program implementing
       this protocol, and HOME_DIR is the directory name of the
       configuration directory for this crypto engine.  If HOME_DIR is
       `NULL', the engine's default will be used.
  
       The new defaults are not applied to already created GPGME contexts.
  
       This function returns the error code `GPG_ERR_NO_ERROR' if
       successful, or an eror code on failure.
  
     The functions `gpgme_ctx_get_engine_info' and
  `gpgme_ctx_set_engine_info' can be used to change the engine
  configuration per context.  *Note Crypto Engine::.
  


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.