[Pkg-gnupg-maint] packaging dirmngr from 2.1.0

[Eric Dorland]

* 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
system certs?
 
>  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
will break?

>  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!
> 
> Regards,
> 
>     --dkg
> 



> _______________________________________________
> Pkg-gnupg-maint mailing list
> Pkg-gnupg-maint at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gnupg-maint


-- 
Eric Dorland <eric at kuroneko.ca>
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: </pipermail/attachments/20141006/452ee54a/attachment.sig>