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 <ijack...@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.
