packaging dirmngr from 2.1.0

[Werner Koch]

On Tue,  7 Oct 2014 01:27, dkg at fifthhorseman.net said:

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

Most of the certificates in com-certs.pem are expired and thus useless.
I will remove most of them for the release anyway.  However I have no
problems to replace that with a mechanism to use the standard CA
certificate bundle.  The original idea by a customer of mine was to be
able to setup a dedicated list of CAs so not not be vulnerable to the
X.509 mess.  Those certificates are automatically installed by gpgsm and
dirmngr falls back to them (for CRLs) if it can't find a trusted
certificate in its own store.  (I like to keep the ca-cert, though ;-).

tls-ca.pem has the root certificate for the hkps keyservers and it
should actually be used by default.  As of now it needs to be explicitly
set using the --hkp-cacert option.  Given that there is some strict
control over the hkps server pool I consider the use of a dedicated
certificate here useful.

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

I would like to get rid of the system service at all but it might be
useful in some rare palces (Squid CRL checking).  The idea for the
design was to avoid the overhead of downloading CRLs for each user and
instead use a system service.  However, multi-user machines used for
trusted communications are a bad idea anyway.

The default shall be the on-demand started dirmngr as a user service
similar to gpg-agent  (using ~/.gnupg/S.dirmgr).

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

(You better don't ask me about helping systemd; I like Unix too much)

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

No.  There is an internal API in dirmngr which should make it easy to
add new helpers.  But dlopening stuff is too troublesome to maintain and
I am glad that we don't need that anymore in GnuPG.  I know that for
Debian it would be easier if users could add there plugins instead of
waiting for the next Debian release.  But from my experience any plugin
system is really troublesome.  I can offer to host a Debian package of
the latest dirmngr at gnupg.org but there is the backports repo anyway.

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

You need to write a wrapper texti like what we did for gnupg-1.  I would
suggest to go wityh just the man pagaes.  If there is something missing
we can easily extract more stuff from the texi file.

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

IIRC, this is so that the main functionality of the new dirmngr
(keyserver access) is not harmed.  But it is a warning anyway:

  if (!access ("/etc/"DIRMNGR_NAME, F_OK) && !strncmp (opt.homedir, "/etc/", 5))
    log_info
      ("NOTE: DirMngr is now a proper part of %s.  The configuration and"
       " other directory names changed.  Please check that no other version"
       " of dirmngr is still installed.  To disable this warning, remove the"
       " directory '/etc/dirmngr'.\n", GNUPG_NAME);

or did I miss something?

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

I can't see that a log file is used by default, thus any logging should
already go to stderr.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.