[pkg-gnupg-maint] Bug#840669: Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Need way to avoid agent,	or reliable way to kill agent"):
> On Fri 2016-10-14 07:10:29 -0400, Ian Jackson wrote:
> > When run under adt-run with a filesystem snapshotting virt server,
> > there is to need (of course) to delete the temporary area, since it's
> > in a filesystem a snapshot which is going to be deleted.
> 
> i think you mean "no need" here, not "to need", right?

Yes.

> There are multiple ways that processes from a given test run could
> potentially linger with files open in that snapshotted filesystem.

Those leftover processes would be bugs.  They aren't always detected,
it's true, particularly in the less-formal ways of running the test
suite.

> gpg-agent happens to be one of them.  what do you propose to do about
> the others?

There are no others.

If others should start to occur then I would want the tests to fail so
that I could arrange for my code not to leak wreckage in the process
table.

So I actively _want_ to detect these leaks and fail on them.

> If dgit is willing to do this work, it should also be willing to just
> invoke "gpgconf --kill gpg-agent" when it's ready to terminate the
> agent, right?  Why craft all this new mechanism and guidance?

That might be possible, but:

1. dgit ought not to start an agent if there's one already running.
So dgit would have to grow code to do that.

2. The agent started by dgit should not be used willy-nilly by other
processes.  The user who types their passphrase to authorise a dgit
push ought not to find that the passphrase has been reused for a
different operation.  (And vice versa.)

3. dgit does in fact not currently have any gnupg2 knowledge at all.
It just runs `gpg' with some very simple command line arguments.
(Consider also `debsign' which could usefully use this feature and is
otherwise a very small program.)

4.  Applications (and users) which are naive (like dgit right now,
before I add any hypothetical key-lifetime-control code) should expect
that the lifetime of authorisation granted to a particular program (by
typing a passphrase at something like pinentry) is limited to that
program.

> >  * The result is that the scope of an auto-spawned agent is a single
> >    GNUPG_AGENT_LIFETIME_FD (normally, a single gnupg2 gpg program).
> >    Other concurrent calls to gpg will block.
> 
> yuck.  I really don't like the idea that all concurrent calls to gpg
> should block.

I think this is an inevitable consequence of the following facts:

 1. An agent process is the repository of authorisation granted via
    pinentry.  (gnupg2 design decision; changed from gnupg1)

 2. In the absence of some kind of ambient desktoppish global pinentry
    setup, authorisation granted via pinentry should be limited to the
    particular command that the user ran or the particular gpg
    invocation.

 2a. If you disagree about that as the default, at the very least,
    such an restricted lifetime model should be available as a
    configuration or runtime option.  (security property)

 3. Concurrent access to the private key database by different
    agents is not safe.  (gnupg2 design decison; I think gnupg1 uses
    locks)

If you want to support *concurrent* use of multiple different
authorisation contexts, with different lifetimes, then you need to
either make a single agent somehow able to keep the different security
contexts separate, or allow there to be multiple concurrent agents.

In the absence of those changes, which would be a major architectural
overhaul, blocking one gnupg because another one is blocked in
pinentry is fairly reasonable.  This would only happen in interactive
situations.

> This proposal represents a major change in how gpg-agent works right
> now.

My proposal represents the re-establishment of the semantics of
gnupg1.

And I think you overestimate the amount of code change involved.

> > This doesn't solve the problem when the test scripts are run ad-hoc.
> > It won't solve the problem for other programs which set HOME (or
> > GNUPGHOME) as part of test suites or whatever.
> 
> right, i agree that there is a general problem here, which is how to
> deal with test suites that involve manipulation of gpg secret key
> material.  It would be great for upstream to produce a clear set of
> instructions that say "if you're dealing with gpg secret key material in
> a test suite, here's what we recommend you do".

I don't think that is a reasonable approach, partly because gnupg may
be called by other programs, and partly because gnupg2 is not entitled
to decree particular misbehaviours (which I'm afraid I think the
current behaviour is) "as designed".

Thanks,
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.