System wide dirmngr configuration with Gnupg 2.1

[Andre Heinecke]

Hi,

On Friday, January 23, 2015 12:19:55 PM Daniel Kahn Gillmor wrote:
> On Fri 2015-01-23 05:14:22 -0500, Andre Heinecke wrote:
> > Yes, I agree with you there. I don't want to force users to this
> > configuration. Users that have a reason could still start a dirmngr with
> > --homedir ~/.gnupg.
> except that it's automatically launched, as you pointed out :/
> 
> > But maybe it really would be better to have dirmngr read the trusted-certs
> > from the sysconfig dir and also from the homedir.
> > 
> > Like:
> > If --homedir is not explicitly set: Read trusted-certs / config from
> > sysconfig dir. Afterwards read trusted-certs / config from homedir and
> > prefer the values from the homedir. This would be more similar to
> > freedesktops config_dirs / config_home handling.
> 
> This is is a pretty common configuration pattern for other (non-gnupg)
> tools.  In fact, i've often wished for it for gnupg itself, so that
> sysadmins could tweak a generic /etc/gnupg/gpg.conf for all their users.
> Is there a specific reason why gpg doesn't support this configuration
> pattern?

Werner? Could you comment on this?

> >  a) I'm not sure if werner plans to support the system-wide mode forever.
> 
> The main difference of the system mode is its use of a modified/split
> directory layout that meets the LFS requirements, right?

I'd say that the main difference is that it runs as root / special user and is 
shared by multiple users.

> Couldn't this also be done with:
> 
>  mkdir -p /var/lib/gnupg/extra-certs /etc/gnupg /var/cache/gnupg/crls.d
> /var/run/gnupg ln -s /var/cache/gnupg/crls.d  /etc/gnupg/dirmngr.conf
> /var/run/gnupg/S.dirmngr /var/lib/gnupg/
> 
> launching dirmngr instead as a system service with:
> 
>  dirmngr --homedir=/var/lib/gnupg
> 
> That could allow us to remove the system mode entirely and have the same
> effect, i think. 

Still this would mean that multiple users share a dirmngr service. This is 
what I'd like to avoid as this is no longer the usual case and might create 
new bugs that are not tested in the usual setup. This setup might also not be 
robust enough. E.g. If this service is unreachable new dirmngr processes are 
automatically started (well we could configure this out too) and you get 
different behavior. 

Basically I like the Idea of a dirmngr that is started on demand and runs in 
the user's context. 

> > And I would not like to stray away from debian packaging so far as to
> > still keep dirmngr started centrally as a service.
> 
> The current plan for the debian packaging is to remove dirmngr as a
> system service after the release of jessie.  I'd be happy to add a new
> binary package that sets up a system service using the above
> configuration, if you want to help make sure it works for you, though.

Thanks. But I'm still hoping that we can avoid packaging a Different Mode.  :-)
 
> >  b) The default should be the system wide config (if it exists) as this is
> >  for> 
> > the users that don't know what a dirmngr is. Those who know / care should
> > be able to overrule it.
> 
> Sure, but to do this approach properly, we should support the
> chained/overriden pattern you describe above, since it's a reasonable,
> established practice.

Right. I think this is the best approach at least for trusted CA's. As it's 
standard practice to have them defined on a system level first and then merge 
those with the users choices.

A generic mechanism for all config files would be nice to have but this is 
probably too intrusive. We could work around this by creating a 
dirmngr_ldapservers.conf in the homedir of all users and adding it to the 
skeleton config. This is not worse then the current way to configure e.g. a 
keyserver in gnupg.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150126/534b65a3/attachment-0001.sig>