[Pkg-gnupg-maint] packaging dirmngr from 2.1.0
eric at debian.org
Tue Oct 7 05:37:49 CEST 2014
* Daniel Kahn Gillmor (dkg at fifthhorseman.net) wrote:
> Hi GnuPG folks--
> I'm still working on the debian experimental packaging for gnupg2's
> 2.1.0 beta, in particular on the dirmngr package. I have some questions
> about the transition to the dirmngr from 2.1.0, and what seems sensible
> From an upstream perspective. If any of these questions are more
> complicated and need to wait for a later response, i'm happy to get the
> easy answers first, and an "i'll deal with this later" for the others :)
> 0) in the old dirmngr source, doc/examples/trusted-certs/ and
> doc/examples/extra-certs/ contained a bunch of X.509 certificates
> which we shipped in the debian package. In the source for the 2.1.0
> beta, i only see doc/com-certs.pem and common/tls-ca.pem (and some
> test certs in tests/) -- should we be shipping any of these certs in
> debian or should we be relying instead on the operating system's
> ca-certificates package (or equivalent) ?
Seems like it would be obviously bad to use anything other than the
> 1) The existing dirmngr 1.1.1 package provides a system service,
> running as the dedicated dirmngr user, listening on
> /var/run/dirmngr/socket. The new one looks like it would run
> /var/run/gnupg2/S.dirmngr. Is the system service something that you
> expect to be used in general, or should users just run their own
> dirmngr instances?
Are we sure that there are no other users of dirmngr that this change
> 2) Whether the system service is relevant or not, it seems like it
> would be useful (at least on linux-based systems) to enable it to be
> handed its listening socket at runtime (e.g. systemd socket-based
> activation, either for system-level services, or for user services).
> Would you be interested in patches that provide socket-handoff at
> runtime? (i'm imagining something like "dirmngr --listen-fd 4")
+1, although does it need to run continuously to keep CRLs up to date?
Does socket activation allow for that?
> 3) it looks like dirmngr has taken over all keyserver interactions,
> which is nice. But the old keyserver interaction mechanism was
> extensible with drop-in programs
> (e.g. /usr/lib/gnupg2/gpg2keys_whatever). Is there a way to provide
> similar extensibility to the new dirmngr? I see
> /usr/lib/gnupg2/dirmngr_ldap, but is there a specification for how
> one can write sometihng similar for other transports?
> 4) I'm trying to generate dirmngr.info from doc/dirmngr.texi, but
> having trouble doing so. "(cd doc && make dirmngr.info)" results in
> a long list of texinfo complaints. Should we be shipping an info
> file for dirmngr, or are the man pages (dirmngr.8 and
> dirmngr-client.1) sufficient and complete? If we should ship a
> .info file, how should i build it?
> 5) The new dirmngr deliberately fails if /etc/dirmngr/ exists (even for
> non-privileged users running dirmngr on their own). This makes a
> transition from the old package to the new package difficult, since
> it's possible that config files from the older package are still
> present. Can this check be relaxed to a warning?
Are those config files no longer used in the newer version?
> 6) logging by default seems to go to /var/log/dirmngr/dirmngr.log, but
> can be reset with --log-file -- but most uses don't have write
> access to /var/log/dirmngr/dirmngr.log (and we probably wouldn't
> want them to). I'm inclined to make it default to logging to
> stderr, and then people who prefer to override the logging (e.g. in
> a system service file, or whatever) can do so explicitly. Does this
> sound reasonable?
> Sorry if i've missed any obvious answers. Pointers are welcome!
> Pkg-gnupg-maint mailing list
> Pkg-gnupg-maint at lists.alioth.debian.org
Eric Dorland <eric at kuroneko.ca>
43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the Gnupg-devel