[pkg-gnupg-maint] Bug#840669: Bug#840669: Bug#840669: Beware of leftover gpg-agent processes

[Ian Jackson]

Lots of this discussion has been focusing on the test suite process
leak problem.  But there are actually three separate use cases which
need something along the lines of my proposal; two of which are
regressions from gnupg1.


1. gnupg1-compatible authorisation lifetime:

Command line use of gpg by users outside of a desktop environment
(or who have disabled desktop environment passphrase sharing).  With
gnupg1 each call to gpg to sign or decrypt something would ask for the
user's authorisation for the specific action.

This is, in many (if not most) contexts a desirable security property.
(It's valuable even, or particularly, if none of the software invoking
gpg is malicious: because software can do unexpected things for other
reasons than malice.)

There should be a way for command line users (including users of
programs which themselves call gnupg) to have the same authorisation
lifetime as with gnupg1.  Personally I think this should be the
default, at least if there is no ambient gpg-agent found.  But even if
it is not going to be the default it should be available as a
configuration option.

I don't think any of the approaches advanced in this thread are able
to provide the gnupg1 authorisation lifetime model.  So this is a
regression in gnupg2 which is not addressed by any of the proposals
other than mine.

This is an especially serious regression in that in this use case
gnupg2 (currently) silently extends the scope of an authorisation in
an unexpected way.


2. Explicit programmatic control of authorisation lifetime:

Programs like debsign and dgit want to do what is in their model a
single high-level operation but which at the crypto level involves
multiple decryptions and/or sigantures.

It would be nice if such a program could, when invoked in a setup
without ambient authorisation, explicitly request authorisation once
and then apply it multiple times.

This is feature which is not present in gnupg1 (at least not without a
lot of explicit code to set up and tear down an agent), but which
would be useful and which I think cannot be provided by any of the
proposals other than mine.


3. Test suite process leakage.

This has been discussed extensively.  There are proposals including
use of inotify, explicit teardown by tools like schroot, and so on,
which address this use case.  They are not 100% perfect but would
probably suffice.


Thanks for your attention.

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.