simplify sharing dirmngr's across multiple GNUPGHOMEs
Open, HighPublic


I'm seeing several instances lately where projects want to use GnuPG internally, but they don't want to share pubrings or secrings between components (e.g. encrypted mailing lists where different lists need to maintain their own keyrings).

however, even in these situations, all of the components might want to share a dirmngr, to take advantage of dirmngr's long-running state and knowledge about the current network status.

I believe these components can already share a dirmngr (i haven't tested it myself) by either symlinking the expected dirmngr socket to a running dirmngr socket, or by using assuan's "socket redirection hack". however, documentation for both of these approaches is sketchy, and there are potentially race conditions and it just feels complicated and fiddly.

it would be great if there were an easy and well-documented way to direct two separate GnuPG instances (gpg and gpgsm, and anything else which uses dirmngr) with different homedirs to share a single running dirmngr instance.

dkg created this task.Jan 31 2018, 7:56 PM
dkg created this object in space S1 Public.
georg added a subscriber: georg.Jan 31 2018, 8:07 PM
werner triaged this task as High priority.Feb 1 2018, 9:26 AM
werner added a project: Documentation.
werner added a subscriber: werner.

Originally dirmngr was designed to be a system service for the reason that CRLs are not user specific. However, the majority of systems today are used by a single user and thus we dropped that feature when integrating dirmngr into gnupg.

Dirmngr keeps a bit of state on disk (CRLs) which is expected to be extended in future versions (a queue of keys to fetch or refresh. Some state can be kep in memory but we need to track it per user. Dirmngr also needs to call gpg for some background tasks: The up-to-date check (loadswdb) would not be a problem because it is global but importing keys fetched by a background task are GNUPGHOME specific.

Some kind of master/slave GNUPHOME for dirmngr might be a solution to this. However, this would be a too large change for 2.2.

For 2.2 we could come up with a workaround and documented this along with its properties.