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

[Daniel Kahn Gillmor]

On Tue 2016-10-18 07:44:43 -0400, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Bug#840669: Beware of leftover gpg-agent processes"):
>> On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote:
>> > 1. gnupg1-compatible authorisation lifetime:
>> 
>> I believe this is a deliberate change in semantics from the upstream
>> GnuPG project.  In particular, authorization for the use of secret key
>> material is now the responsibility of the gpg-agent.  This is an overall
>> win, because it means that no process ever gets access to the secret key
>> in memory *except* for the gpg-agent.
>
> I think these properties about key material handling are good, but
> this is not the same question as the authorisation lifetime.  You are
> conflating two separate things.

I agree that these are distinct choices, but their implementation
details are closely linked.

>>  The gpg-agent is where these decisions are made.
>
> Actually, though, it just acts as an oracle, so it does not make any
> decisions.

It is making a decision about whether to grant use of a given key.  For
example, it's possible to ask gpg-agent to prompt the user to confirm
the use of any ssh-capable key.  (i'm unaware of how to ask it for user
confirmation for other, non-ssh keys, though)

If the current decision-making policy language isn't descriptive enough
for your goals, we should clarify what those goals are and try to figure
out a way that you can express them to the agent.  That's distinct from 

>> If you want an agent that never caches any passphrase (and therefore has
>> a one-use-per-authorization), this is an easy thing to do by adjusting
>> max-cache-ttl in gpg-agent.conf.  you can also set this dynamically with
>> gpgconf (see the --runtime option in gpgconf(1)).
>
> It sounds like this is very close to what I want for the authorisation
> lifetime qeustion (provided that it isn't racy).  Why is this not the
> default for command line users without a session-provided agent ?

I think the goal is to provide uniform behavior, regardless of whether
the agent is session-provided or otherwise, instead of having a subtle
difference between an auto-launched agent and an explicitly-initialized
agent.  Perhaps Werner can speak more to this decision, though.

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161018/6f45b9d5/attachment.sig>