Page MenuHome GnuPG
Create Task
Maniphest T3767

simplify sharing dirmngr's across multiple GNUPGHOMEs
Open, NormalPublic
Actions

Description

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.

Event Timeline

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.

• werner lowered the priority of this task from High to Normal.Apr 9 2019, 8:59 AM

I don't anymore think this is a high priority request. BTW, A more real problem than several dirmngr instances is multi-user access to smartcards.

dkg added a comment.Apr 10 2019, 2:52 AM

One of the things that dirmngr has going for it is that it tracks the current network state, and it would be nice to be able to reuse that state across sessions. If an ephemeral keyring can't use a shared dirmngr, there are fewer arguments for having dirmngr in the first place, and people might be more justified in replacing it with things like https://gitlab.com/anarcat/scripts/blob/master/openpgp-key-get

So i'm sorry to hear that shared dirmngr is deprioritized, but i think i can understand it.

multi-user access to smartcards is an entirely separate issue -- please open it as a distinct ticket so we can keep track of it (or point to the already-opened ticket so that whoever stumbles across this later can figure out where to follow up). thanks!