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

[Werner Koch]

On Fri, 14 Oct 2016 21:47, d...@fifthhorseman.net said:

>> In a new temp directory do:
>>
>>  GNUPGHOME=$(pwd) gpg-agent --daemon gpg .
>>
>> Or whatever you want to run under gpg-agent's control.  This has been
>> there for ages.
>
> fwiw, this doesn't work (and actually returns an error) if there is
> already a gpg-agent running in that $GNUPGHOME:

That is why I wrote "in a _new_ teemp directory" above .-)


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpeZ_IPkapdL.pgp
Description: PGP signature

Re: [pkg-gnupg-maint] 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


signature.asc
Description: PGP signature

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

[Ian Jackson]

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.

>  The gpg-agent is where these decisions are made.

Actually, though, it just acts as an oracle, so it does not make any
decisions.

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

> Thanks for your engagement on this issue, Ian.

Thank you for being so tolerant of me being argumentative !

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

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

[Daniel Kahn Gillmor]

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.  The gpg-agent is where these
decisions are made.

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)).

> 2. Explicit programmatic control of authorisation lifetime:

This is also present in some form with the current gpg, but there are a
couple different ways to do it -- you can still set up and tear down a
separate gpg-agent (though managing that independently from other
sessions can be tricky); you can set authorization cache times that
are bounded to the times you prefer; or you can explicitly tear down the
agent after a given run.

btw, upstream now has fixes to the inotify teardown approach, which i
hope to land in debian unstable in the next day or two.

Thanks for your engagement on this issue, Ian.

  --dkg


signature.asc
Description: PGP signature

Re: [pkg-gnupg-maint] 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    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.

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

[Daniel Kahn Gillmor]

On Fri 2016-10-14 15:18:40 -0400, Werner Koch wrote:
> On Fri, 14 Oct 2016 19:17, ijack...@chiark.greenend.org.uk said:
>
>> authorisations, if the user types in a passphrase) have a lifetime
>> limited by that of the gpg process which started the agent.
>
> In a new temp directory do:
>
>  GNUPGHOME=$(pwd) gpg-agent --daemon gpg .
>
> Or whatever you want to run under gpg-agent's control.  This has been
> there for ages.

fwiw, this doesn't work (and actually returns an error) if there is
already a gpg-agent running in that $GNUPGHOME:

0 dkg@alice:/tmp/cdtemp.ofhjoX$ export GNUPGHOME=$(pwd)
0 dkg@alice:/tmp/cdtemp.ofhjoX$ gpg-connect-agent /bye
gpg-connect-agent: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established.
2 dkg@alice:/tmp/cdtemp.ofhjoX$ ls
private-keys-v1.d  S.gpg-agentS.gpg-agent.rstrd  trustdb.gpg
pubring.kbxS.gpg-agent.brwsr  S.gpg-agent.ssh
0 dkg@alice:/tmp/cdtemp.ofhjoX$ gpg-agent --daemon ls
gpg-agent: a gpg-agent is already running - not starting a new one
2 dkg@alice:/tmp/cdtemp.ofhjoX$ 


  --dkg


signature.asc
Description: PGP signature