Re: [pkg-gnupg-maint] Bug#840669: Beware of leftover gpg-agent processes (was: Re: Changes for GnuPG in debian)
On Fri, Oct 14, 2016 at 03:21:43PM -0400, Daniel Kahn Gillmor wrote: > On Fri 2016-10-14 13:17:06 -0400, Ian Jackson wrote: > > This (and the change to gnupg2) has now broken dgit's DEP-8 test > > suite, when run under schroot. I'm discussing this in #840669 (CC'd). > > in particular, the lack of a cleanup process breaks the test suite. If > the test suite had a cleanup process, we know exactly how to "un-break" > things. > > > I am trying to persaude Daniel that we should provide (at least > > optionally) a mode where an autostarted agent (and the corresponding > > authorisations, if the user types in a passphrase) have a lifetime > > limited by that of the gpg process which started the agent. > > fwiw, i'm not the person who needs persuading. Ian's proposal is rather > complex, seems likely to introduce new problems, and it isn't a change > i'm up for either writing myself or supporting as a divergence from > GnuPG upstream. > > The simple fix (cleaning up the test suite by eithe deleting the > temporary GNUPGHOME directory or by invoking "gpgconf --kill gpg-agent") > is a lot more straightforward. I had to make a similar change[0] for devscripts' test suite, and it was indeed pretty straightforward. The biggest hurdle was my fingers making typos. Granted, the code to create the temporary GNUPGHOME for the test was already there, so it was just a matter of killing the agent. Supporting setup and teardown around a test suite/case seems pretty typical. Heck, even sh supports performing an action on exit (via trap). [0]: https://anonscm.debian.org/cgit/collab-maint/devscripts.git/commit/?id=4038fbd93536c17ec2ad9cdb1b68acaae5782184&context=3&ignorews=1&dt=0 Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: [pkg-gnupg-maint] Bug#840669: Beware of leftover gpg-agent processes (was: Re: Changes for GnuPG in debian)
On Fri 2016-10-14 13:17:06 -0400, Ian Jackson wrote: > This (and the change to gnupg2) has now broken dgit's DEP-8 test > suite, when run under schroot. I'm discussing this in #840669 (CC'd). in particular, the lack of a cleanup process breaks the test suite. If the test suite had a cleanup process, we know exactly how to "un-break" things. > I am trying to persaude Daniel that we should provide (at least > optionally) a mode where an autostarted agent (and the corresponding > authorisations, if the user types in a passphrase) have a lifetime > limited by that of the gpg process which started the agent. fwiw, i'm not the person who needs persuading. Ian's proposal is rather complex, seems likely to introduce new problems, and it isn't a change i'm up for either writing myself or supporting as a divergence from GnuPG upstream. The simple fix (cleaning up the test suite by eithe deleting the temporary GNUPGHOME directory or by invoking "gpgconf --kill gpg-agent") is a lot more straightforward. Alternately, if schroot was to run under a session management supervisor like systemd, then the session manager could take care of both launching and terminating the agent as needed. --dkg signature.asc Description: PGP signature
Beware of leftover gpg-agent processes (was: Re: Changes for GnuPG in debian)
Ian Jackson writes ("Beware of leftover gpg-agent processes (was: Re: Changes
for GnuPG in debian)"):
> Johannes Schauer writes ("Beware of leftover gpg-agent processes (was: Re:
> Changes for GnuPG in debian)"):
>
> > Quoting Daniel Kahn Gillmor (2016-08-04 18:29:03)
> > > One of the main differences is that all access to your secret key
> > > will be handled through gpg-agent, which should be automatically
> > > launched as needed.
> >
> > it might be important to note that gpg launching this gpg-agent
> > process is not optional and that it will automatically be launched
> > and continue running in the background for many gpg operations.
>
> This is rather alarming. As a longtime gpg1 user I hadn't appreciated
> this.
>
> Could we not have gpg2 not only automatically launch the agent, but
> also automatically terminate it. This would provide the same UI and
> same persistence properties as gpg1.
>
> I don't think a general change to a timeout-based persistence model is
> a good idea in itself; and of course there are the practical problems
> Johannes mentions.
This (and the change to gnupg2) has now broken dgit's DEP-8 test
suite, when run under schroot. I'm discussing this in #840669 (CC'd).
I am trying to persaude Daniel that we should provide (at least
optionally) a mode where an autostarted agent (and the corresponding
authorisations, if the user types in a passphrase) have a lifetime
limited by that of the gpg process which started the agent.
Ian.
--
Ian JacksonThese 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.
Beware of leftover gpg-agent processes (was: Re: Changes for GnuPG in debian)
Johannes Schauer writes ("Beware of leftover gpg-agent processes (was: Re:
Changes for GnuPG in debian)"):
> Quoting Daniel Kahn Gillmor (2016-08-04 18:29:03)
> > One of the main differences is that all access to your secret key
> > will be handled through gpg-agent, which should be automatically
> > launched as needed.
>
> it might be important to note that gpg launching this gpg-agent
> process is not optional and that it will automatically be launched
> and continue running in the background for many gpg operations.
This is rather alarming. As a longtime gpg1 user I hadn't appreciated
this.
Could we not have gpg2 not only automatically launch the agent, but
also automatically terminate it. This would provide the same UI and
same persistence properties as gpg1.
I don't think a general change to a timeout-based persistence model is
a good idea in itself; and of course there are the practical problems
Johannes mentions.
Ian.
Beware of leftover gpg-agent processes (was: Re: Changes for GnuPG in debian)
Hi, Quoting Daniel Kahn Gillmor (2016-08-04 18:29:03) > One of the main differences is that all access to your secret key will be > handled through gpg-agent, which should be automatically launched as needed. it might be important to note that gpg launching this gpg-agent process is not optional and that it will automatically be launched and continue running in the background for many gpg operations. This means, that applications that use gpg from within a short-lived container (like during package builds, for example as part of a test suite) should probably add a gpgconf --kill gpg-agent somewhere after they are done with all gpg related operations or otherwise it will be impossible to unmount /dev from the container until gpg-agent died after a timeout. It is also important to note that not all versions of gpgconf have the --kill switch. This command must be run with the same $GNUPGHOME that was used to run gpg. Doing this might be made complicated if your scripts do not call gpg directly but use tools that in turn call gpg. For example apt-key uses a temporary $GNUPGHOME which is removed after apt-key exits and thus it is impossible to use "gpgconf --kill gpg-agent" to kill the gpg-agent process left by apt-key. This was fixed in the apt git, but there might be similar situations around. Thanks! cheers, josch signature.asc Description: signature
