packaging dirmngr from 2.1.0

[Daniel Kahn Gillmor]

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) ?

 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?

 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")

 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?

 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141006/e0715a08/attachment-0001.sig>