[Pkg-gnupg-maint] packaging dirmngr from 2.1.0

[Daniel Kahn Gillmor]

Hi Eric--

On 10/06/2014 11:37 PM, Eric Dorland wrote:
> * Daniel Kahn Gillmor (dkg at fifthhorseman.net) wrote:
>>  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?

It would be good to know from upstream whether there is any expectation
of built-in certs, specific formats desired/needed, etc.

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

0 dkg at alice:~$ apt-cache rdepends dirmngr
dirmngr
Reverse Depends:
  gpgsm
  dirmngr:i386
  kleopatra
  gpgsm
0 dkg at alice:~$

So the only package outside of gnupg2 that we need to think about is
kleopatra.  I don't think that kleopatra depends on the system service
-- looking at the kdepim source code, it appears to try to invoke
dirmngr on its own, directly, rather than looking for a system socket.

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

the idea behind socket activation is that the service doesn't need to be
started until someone actually queries it.

But once queried, it can persist and keep doing whatever it needs to do
in the background (like checking CRLs).

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

Those config files are now moved to /etc/gnupg2/ instead of
/etc/dirmngr/, but by default i don't know that they need to be present
at all.  However, if they aren't present, the dirmngr system service
does complain about the lack of /etc/gnupg2/ldapservers.conf

For simplicity, i'm considering setting up the experimental dirmngr
package to not have the system service at all, since it makes the
packaging simpler and clearer.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141007/69aaacfb/attachment.sig>