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
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 authorisa
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 se
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
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 b
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
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
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:
>
> GNUPGHO
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 proc
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
On Sat, Aug 06, 2016 at 12:56:58PM -0400, Daniel Kahn Gillmor wrote:
> ouch! please do file this as a distinct bug report, it's something i
> haven't run into myself and i'd like to track it down.
Done, that's #833596.
Cheers.
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . .
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 icon
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 smartcar
On Sat, 6 Aug 2016 08:24, p...@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
been done and I am not sure whether we will have it for 2.2.
Shalom-Salam,
Werner
--
Die Gedanken sind fr
[ 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 user@.service like this:
[...]
> If
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 upgrad
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, ju
On Fri 2016-08-05 15:03:29 -0400, Peter Colberg wrote:
> 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 det
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 pre
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 servi
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}/READ
On Fri 2016-08-05 13:39:10 -0400, Peter Colberg 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,
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}/READ
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
>
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
only comm
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 g
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
27 matches
Mail list logo
