Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Beware of leftover gpg-agent processes (was: Re: Changes for GnuPG in debian)
1,343 views
Skip to first unread message
Johannes Schauer
Aug 4, 2016, 1:20:03 PM8/4/16
to
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
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
Ian Jackson
Aug 5, 2016, 12:10:03 PM8/5/16
to
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.
> 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.
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.
Christian Seiler
Aug 5, 2016, 12:40:03 PM8/5/16
to
On 08/05/2016 06:08 PM, Ian Jackson wrote:
> 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.
Full ACK here, with the slight modification that the agent should
> 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.
only communicate with the gpg2 process that launched it.
I think that if an agent is wanted, the user should explicitly start
it. I'd even be fine with Debian changing the defaults to autostart
an agent in the background in login sessions, and documenting that,
because that's at least explicit configuration. But autostarting
something in the background and have it persist - I think that's a
huge no-go, because of the surprise factor. (Plus in contrast to an
agent started at login, process context is inherited, which could
be a whole other can of worms for something persistent... There's a
good reason why autolaunching the DBus session daemon when it's not
already running has now been deprecated for quite some time.)
I've been using gpg2 explicitly for a while now (because gpg1 doesn't
work with my YubiKey), and I didn't know that. In my case, it isn't
a huge deal, because I do run an agent in the background anyway (and
know of it), but I also have some scripts that call gpg internally
with different GPGHOME (luckily at the moment still gpg1) and I would
really not have expected the gpg calls to start an agent in the
background.
Regards,
Christian
Daniel Kahn Gillmor
Aug 5, 2016, 1:00:02 PM8/5/16
to
Ian Jackson writes:
> 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.
There are good reasons to want to have the agent running over time and
> 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.
not terminating with the individual invocations of gpg1. In particular,
passphrase caching and smartcard management are useful features.
The UI of gpg1 (where the user is expected to reveal the secret key
material and any passphrase to unlock it directly to the running
process) is not a feature we want to emulate.
GnuPG upstream hasn't designed any automated agent teardown process that
i can see simply integrating into debian's typical session-oriented
workflow (though i'd happily take patches that don't break common use
cases).
On desktop systems (where i'd expect the majority of secret key access
happens), for folks who are running systemd, i recommend enabling the
systemd user services, as documented in
/usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
systemctl --user enable gpg-agent
systemctl --user enable dirmngr
This should handle teardown at session termination cleanly.
> 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.
to enable them (on systems which use systemd) by default after they've
had a bit more testing in the real world.
(relevant bugs that need work, if anyone is inclined to help:
https://bugs.debian.org/764678
https://bugs.debian.org/830658
)
Regards,
--dkg
PS Please keep me or at least pkg-gnupg-maint in Cc, i'm not subscribed
to debian-devel.
Peter Colberg
Aug 5, 2016, 1:50:03 PM8/5/16
to
On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> On desktop systems (where i'd expect the majority of secret key access
> happens), for folks who are running systemd, i recommend enabling the
> systemd user services, as documented in
> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
>
> systemctl --user enable gpg-agent
> systemctl --user enable dirmngr
In this case one should also add
> On desktop systems (where i'd expect the majority of secret key access
> happens), for folks who are running systemd, i recommend enabling the
> systemd user services, as documented in
> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
>
> systemctl --user enable gpg-agent
> systemctl --user enable dirmngr
no-autostart
to ~/.gnupg/gpg.conf (or ~/.gnupg/gpg.conf-2 when using gpg1 in parallel).
Peter
Stefano Zacchiroli
Aug 5, 2016, 2:20:02 PM8/5/16
to
On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> On desktop systems (where i'd expect the majority of secret key access
> happens), for folks who are running systemd, i recommend enabling the
> systemd user services, as documented in
> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
>
> systemctl --user enable gpg-agent
> systemctl --user enable dirmngr
Thanks for the tip. Do you know if this is needed also for GNOME (or
> happens), for folks who are running systemd, i recommend enabling the
> systemd user services, as documented in
> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
>
> systemctl --user enable gpg-agent
> systemctl --user enable dirmngr
other FreeDesktop) session users? Within GNOME, on Debian testing, I see
that my running gpg-agent process is already a directly child of systemd
(PID 1), but I'm not sure if that's because it has been started by it,
or rather because the GPG process who originally spawned it is now gone.
FWIW gpg-agent/dirmngr are currently _not_ marked as enabled in my user
session, I've checked with (systemctl --user status).
Thanks a lot for your work on GPG dkg, I'm really thrilled to see gpg2
becoming the default!
Cheers.
--
Stefano Zacchiroli . . . . . . . za...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
Daniel Kahn Gillmor
Aug 5, 2016, 2:50:04 PM8/5/16
to
On Fri 2016-08-05 14:17:23 -0400, Stefano Zacchiroli wrote:
> On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
>> On desktop systems (where i'd expect the majority of secret key access
>> happens), for folks who are running systemd, i recommend enabling the
>> systemd user services, as documented in
>> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
>>
>> systemctl --user enable gpg-agent
>> systemctl --user enable dirmngr
>
> Thanks for the tip. Do you know if this is needed also for GNOME (or
> other FreeDesktop) session users? Within GNOME, on Debian testing, I see
> that my running gpg-agent process is already a directly child of systemd
> (PID 1), but I'm not sure if that's because it has been started by it,
> or rather because the GPG process who originally spawned it is now gone.
gpg-agent and dirmngr "background" themselves, so they'll always have
> On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
>> On desktop systems (where i'd expect the majority of secret key access
>> happens), for folks who are running systemd, i recommend enabling the
>> systemd user services, as documented in
>> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
>>
>> systemctl --user enable gpg-agent
>> systemctl --user enable dirmngr
>
> Thanks for the tip. Do you know if this is needed also for GNOME (or
> other FreeDesktop) session users? Within GNOME, on Debian testing, I see
> that my running gpg-agent process is already a directly child of systemd
> (PID 1), but I'm not sure if that's because it has been started by it,
> or rather because the GPG process who originally spawned it is now gone.
ppid 1.
that said, under systemd, they'll be grouped into control groups on the
basis of how/where they were launched.
The simplest way to see the control group hierarchy is with "systemctl
status". When these processes are launched by the user service, they'll
end up in the us...@NNNN.service like this:
└─user.slice
├─user-1000.slice
│ ├─session-1.scope
│ │ ├─ 2884 /usr/bin/rxvt
│ │ ├─32603 less
[…]
│ │ ├─32605 rxvt -geometry 80x26
│ │ └─32606 bash
│ └─us...@1000.service
│ ├─gpg-agent.service
│ │ ├─ 2804 /usr/bin/gpg-agent --daemon --homedir /home/dkg/.gnupg
│ │ └─23655 scdaemon --multi-server
│ ├─dirmngr.service
│ │ └─2805 /usr/bin/dirmngr --daemon --homedir /home/dkg/.gnupg
[…]
If they've been autolaunched, they'll end up in the sesion-X.scope
sub-tree.
> FWIW gpg-agent/dirmngr are currently _not_ marked as enabled in my user
> session, I've checked with (systemctl --user status).
https://bugs.debian.org/764678.
> Thanks a lot for your work on GPG dkg, I'm really thrilled to see gpg2
> becoming the default!
--dkg
Peter Colberg
Aug 5, 2016, 3:10:02 PM8/5/16
to
On Fri, Aug 05, 2016 at 01:51:07PM -0400, Daniel Kahn Gillmor wrote:
> I don't think there's any need to add no-autostart in this case. in
> particular, the daemon will already be running, so any consideration of
> autostart will just detect and make use of the already-running daemon.
This is precaution to detect when the daemons are *not* running, e.g.,
> I don't think there's any need to add no-autostart in this case. in
> particular, the daemon will already be running, so any consideration of
> autostart will just detect and make use of the already-running daemon.
if the systemd services have not been started due to misconfiguration.
Peter
Daniel Kahn Gillmor
Aug 5, 2016, 4:10:02 PM8/5/16
to
seems likely that the autostarted daemons would fail in the same way,
which would result in the same situation. But at least the tools would
try to start them if they see that they're not available. and autostart
probably needs to be present for non-systemd systems anyway, right?
My long-term goal is to have these things Just Work without *any*
explicit user intervention.
That is, i want: "If the package is installed, it should work for you."
and not: "oh, if you want things to actually work, just fiddle these
bits in that file over here." Debian should provide a high level of
simple and easy system integration where it can.
by adding no-autostart, we'd be saying "in case your systemd service
can't start the agent, then we don't want to even try to start up the
agent." but i think it would be better to actually try, since it's
likely that this is what the user wants to do.
--dkg
Peter Colberg
Aug 5, 2016, 9:00:02 PM8/5/16
to
On Fri, Aug 05, 2016 at 04:02:07PM -0400, Daniel Kahn Gillmor wrote:
> My long-term goal is to have these things Just Work without *any*
> explicit user intervention.
>
> That is, i want: "If the package is installed, it should work for you."
> and not: "oh, if you want things to actually work, just fiddle these
> bits in that file over here." Debian should provide a high level of
> simple and easy system integration where it can.
>
> by adding no-autostart, we'd be saying "in case your systemd service
> can't start the agent, then we don't want to even try to start up the
> agent." but i think it would be better to actually try, since it's
> likely that this is what the user wants to do.
I fully agree with you. I did not mean to suggest defaulting to this
> My long-term goal is to have these things Just Work without *any*
> explicit user intervention.
>
> That is, i want: "If the package is installed, it should work for you."
> and not: "oh, if you want things to actually work, just fiddle these
> bits in that file over here." Debian should provide a high level of
> simple and easy system integration where it can.
>
> by adding no-autostart, we'd be saying "in case your systemd service
> can't start the agent, then we don't want to even try to start up the
> agent." but i think it would be better to actually try, since it's
> likely that this is what the user wants to do.
option. I merely mentioned no-autostart since it might be useful for
developers testing the gnupg2 package with session-managed daemons.
In this case one wishes to know with certainty whether the daemons were
started by the session manager as intended, or auto-spawned by accident.
Adding to Stefano, thank you very much for completing this transition.
Regards,
Peter
Paul Wise
Aug 6, 2016, 2:30:02 AM8/6/16
to
On Sat, Aug 6, 2016 at 12:41 AM, Daniel Kahn Gillmor wrote:
> There are good reasons to want to have the agent running over time and
> not terminating with the individual invocations of gpg1. In particular,
> passphrase caching and smartcard management are useful features.
I noticed after upgrading gnupg to experimental and monkeysphere to
> There are good reasons to want to have the agent running over time and
> not terminating with the individual invocations of gpg1. In particular,
> passphrase caching and smartcard management are useful features.
unstable, monkeysphere now has gpg-agent processes running as root:
$ pgrep -a gpg | grep -i monk
27043 gpg-agent --homedir /var/lib/monkeysphere/authentication/core
--use-standard-socket --daemon
27061 gpg-agent --homedir /var/lib/monkeysphere/authentication/sphere
--use-standard-socket --daemon
> systemctl --user enable dirmngr
BTW, does this make parcimonie obsolete? I noticed that dirmngr
suggests tor and the gnupg package in experimental still suggests
parcimonie.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Stefano Zacchiroli
Aug 6, 2016, 6:40:02 AM8/6/16
to
[ quoted text reordered ]
On Fri, Aug 05, 2016 at 02:43:30PM -0400, Daniel Kahn Gillmor wrote:
> The simplest way to see the control group hierarchy is with "systemctl
> status". When these processes are launched by the user service, they'll
> end up in the us...@NNNN.service like this:
[...]
> > On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> >> On desktop systems (where i'd expect the majority of secret key access
> >> happens), for folks who are running systemd, i recommend enabling the
> >> systemd user services, as documented in
> >> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
> >>
> >> systemctl --user enable gpg-agent
> >> systemctl --user enable dirmngr
OTOH, doing this inhibited a proper start of my GNOME session at next
login: only Nautilus started (I can tell because I've it handle my
desktop icons) and I could use it to browse the filesystem, but GNOME
Shell didn't see to be running. Reverting the above with "disable" [*]
fixed the issue, and at next login GNOME session started properly,
including GNOME Shell.
I haven't yet filed this as a bug report, because my package mix is
kinda unusual at present: Debian testing + hand-picked gpg from
experimental. But it might be useful for you to know about this. Let me
know how I can debug it further and/or if you'd like to move this
discussion into a dedicated bug report (and when).
Cheers.
[*] actually, I manually removed the symlinks from
.config/systemd/user/default.target.wants/, but AFAICT the effect is
the same
On Fri, Aug 05, 2016 at 02:43:30PM -0400, Daniel Kahn Gillmor wrote:
> The simplest way to see the control group hierarchy is with "systemctl
> status". When these processes are launched by the user service, they'll
> end up in the us...@NNNN.service like this:
> If they've been autolaunched, they'll end up in the sesion-X.scope
> sub-tree.
It was indeed the case for me: they had been auto-launched.
> sub-tree.
> > On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> >> On desktop systems (where i'd expect the majority of secret key access
> >> happens), for folks who are running systemd, i recommend enabling the
> >> systemd user services, as documented in
> >> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
> >>
> >> systemctl --user enable gpg-agent
> >> systemctl --user enable dirmngr
login: only Nautilus started (I can tell because I've it handle my
desktop icons) and I could use it to browse the filesystem, but GNOME
Shell didn't see to be running. Reverting the above with "disable" [*]
fixed the issue, and at next login GNOME session started properly,
including GNOME Shell.
I haven't yet filed this as a bug report, because my package mix is
kinda unusual at present: Debian testing + hand-picked gpg from
experimental. But it might be useful for you to know about this. Let me
know how I can debug it further and/or if you'd like to move this
discussion into a dedicated bug report (and when).
Cheers.
[*] actually, I manually removed the symlinks from
.config/systemd/user/default.target.wants/, but AFAICT the effect is
the same
Werner Koch
Aug 6, 2016, 12:30:03 PM8/6/16
to
On Sat, 6 Aug 2016 08:24, pa...@debian.org said:
> BTW, does this make parcimonie obsolete? I noticed that dirmngr
We plan to add similar fucntionality to dirmngr but that has not yet
> BTW, does this make parcimonie obsolete? I noticed that dirmngr
been done and I am not sure whether we will have it for 2.2.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* Join us at OpenPGP.conf <https://openpgp-conf.org> */
Daniel Kahn Gillmor
Aug 6, 2016, 1:10:03 PM8/6/16
to
On Sat 2016-08-06 06:32:39 -0400, Stefano Zacchiroli wrote:
>> >> systemctl --user enable gpg-agent
>> >> systemctl --user enable dirmngr
>
> OTOH, doing this inhibited a proper start of my GNOME session at next
> login: only Nautilus started (I can tell because I've it handle my
> desktop icons) and I could use it to browse the filesystem, but GNOME
> Shell didn't see to be running. Reverting the above with "disable" [*]
> fixed the issue, and at next login GNOME session started properly,
> including GNOME Shell.
>
> I haven't yet filed this as a bug report, because my package mix is
> kinda unusual at present: Debian testing + hand-picked gpg from
> experimental. But it might be useful for you to know about this. Let me
> know how I can debug it further and/or if you'd like to move this
> discussion into a dedicated bug report (and when).
ouch! please do file this as a distinct bug report, it's something i
>> >> systemctl --user enable gpg-agent
>> >> systemctl --user enable dirmngr
>
> OTOH, doing this inhibited a proper start of my GNOME session at next
> login: only Nautilus started (I can tell because I've it handle my
> desktop icons) and I could use it to browse the filesystem, but GNOME
> Shell didn't see to be running. Reverting the above with "disable" [*]
> fixed the issue, and at next login GNOME session started properly,
> including GNOME Shell.
>
> I haven't yet filed this as a bug report, because my package mix is
> kinda unusual at present: Debian testing + hand-picked gpg from
> experimental. But it might be useful for you to know about this. Let me
> know how I can debug it further and/or if you'd like to move this
> discussion into a dedicated bug report (and when).
haven't run into myself and i'd like to track it down.
thanks for catching it!
--dkg
Daniel Kahn Gillmor
Aug 6, 2016, 1:10:03 PM8/6/16
to
On Sat 2016-08-06 02:24:24 -0400, Paul Wise wrote:
> On Sat, Aug 6, 2016 at 12:41 AM, Daniel Kahn Gillmor wrote:
>
>> There are good reasons to want to have the agent running over time and
>> not terminating with the individual invocations of gpg1. In particular,
>> passphrase caching and smartcard management are useful features.
>
> I noticed after upgrading gnupg to experimental and monkeysphere to
> unstable, monkeysphere now has gpg-agent processes running as root:
>
> $ pgrep -a gpg | grep -i monk
> 27043 gpg-agent --homedir /var/lib/monkeysphere/authentication/core
> --use-standard-socket --daemon
> 27061 gpg-agent --homedir /var/lib/monkeysphere/authentication/sphere
> --use-standard-socket --daemon
it makes sense that this would happen, as monkeysphere-authentication
> On Sat, Aug 6, 2016 at 12:41 AM, Daniel Kahn Gillmor wrote:
>
>> There are good reasons to want to have the agent running over time and
>> not terminating with the individual invocations of gpg1. In particular,
>> passphrase caching and smartcard management are useful features.
>
> I noticed after upgrading gnupg to experimental and monkeysphere to
> unstable, monkeysphere now has gpg-agent processes running as root:
>
> $ pgrep -a gpg | grep -i monk
> 27043 gpg-agent --homedir /var/lib/monkeysphere/authentication/core
> --use-standard-socket --daemon
> 27061 gpg-agent --homedir /var/lib/monkeysphere/authentication/sphere
> --use-standard-socket --daemon
does use secret key material for maintaining its list of system
authenticators.
If you think this is a problem, please open a bug report against the
monkeysphere package and we'll see what we can do about it.
>> systemctl --user enable dirmngr
>
> BTW, does this make parcimonie obsolete? I noticed that dirmngr
> suggests tor and the gnupg package in experimental still suggests
> parcimonie.
refreshes. it would be great if it did, but that's probably something
to work on with dirmngr upstream. See:
https://bugs.gnupg.org/gnupg/issue1827
I know there's some ongoing work on this by other folks too. if you (or
anyone) is interested, please follow up with me off-list about where
that stands.
happy hacking,
--dkg
Ian Jackson
Oct 14, 2016, 1:20:03 PM10/14/16
to
Ian Jackson writes ("Beware of leftover gpg-agent processes (was: Re: Changes for GnuPG in debian)"):
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 Jackson <ijac...@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.
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 Jackson <ijac...@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.
Daniel Kahn Gillmor
Oct 14, 2016, 3:30:02 PM10/14/16
to
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
> 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).
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.
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
Werner Koch
Oct 14, 2016, 3:30:03 PM10/14/16
to
On Fri, 14 Oct 2016 19:17, ijac...@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:
> authorisations, if the user types in a passphrase) have a lifetime
> limited by that of the gpg process which started the agent.
GNUPGHOME=$(pwd) gpg-agent --daemon gpg .....
Or whatever you want to run under gpg-agent's control. This has been
there for ages.
Salam-Shalom,
Daniel Kahn Gillmor
Oct 14, 2016, 4:00:07 PM10/14/16
to
On Fri 2016-10-14 15:18:40 -0400, Werner Koch wrote:
> On Fri, 14 Oct 2016 19:17, ijac...@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
> On Fri, 14 Oct 2016 19:17, ijac...@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.
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-agent S.gpg-agent.rstrd trustdb.gpg
pubring.kbx S.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
James McCoy
Oct 14, 2016, 9:50:02 PM10/14/16
to
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
> 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.
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
Ian Jackson
Oct 15, 2016, 11:30:02 AM10/15/16
to
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.
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.
Daniel Kahn Gillmor
Oct 18, 2016, 12:40:03 AM10/18/16
to
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
> 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:
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
Ian Jackson
Oct 18, 2016, 7:50:02 AM10/18/16
to
Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Bug#840669: Beware of leftover gpg-agent processes"):
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,
> 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
> > 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.
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.
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)).
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.
Regards,
Daniel Kahn Gillmor
Oct 18, 2016, 4:50:02 PM10/18/16
to
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
> 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.
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.
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 ?
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
Werner Koch
Oct 19, 2016, 2:50:03 PM10/19/16
to
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 .-)
>> 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:
Shalom-Salam,
tcarut...@gmail.com
Oct 19, 2016, 8:40:02 PM10/19/16
to
Sent from my iPhone
gthy
0 new messages