pipe passphrase to unlock key
Ciprian Dorin Craciun
ciprian.craciun at gmail.com
Tue Jul 31 17:53:50 CEST 2012
On Tue, Jul 31, 2012 at 6:35 PM, Werner Koch <wk at gnupg.org> wrote:
> On Tue, 31 Jul 2012 12:54, ciprian.craciun at gmail.com said:
>
>>> Not a good idea, because GnuPG 2.1 requires the gpg-agent and won't see
>>> any private key stuff.
>>
>> Not necessarily if you use the `--batch`, `--no-use-agent`, or
>> `--no-tty` (or a mix of the I'm not sure right now, but the manual
>
> Nope. Recall that I implemented the stuff.
(Sorry I didn't knew you've implemented it.) :)
Mmm... Didn't read the "fine print" of the manual... (Which isn't
that fine print...)
~~~~
--no-use-agent
This is dummy option. gpg2 always requires the agent.
~~~~
Then I'm a little bit at unease...
First of all I would really have liked the tool to not just ignore
the `--no-user-agent` flag and bail out...
Then if I use the `--batch` option it doesn't ask for a password,
thus what is the purpose of the agent anymore? (Except handling cards
which isn't the case in most instances...)
>> But on the other side, not always you have the option of running a
>> `gpg-agent` (for example on server side of a background job, etc.),
>
> I run it on servers ;-).
I bet you can run it on servers. And I bet it works nicely.
What I also bet is that it leaves dangling "background" processes
lying, because -- if I'm correct -- the following happens:
* if I implement a service that isn't started with an `gpg-agent`
properly set up, then
* each invocation of `gpg2` will start its own, but not as a
child, but by making it double fork in the background;
* but unfortunately the tool won't be able to export that
environment variables to its parent...
* and also after the invocation the agent would just remain there;
Maybe the tool would check if someone listens on the socket and
not restart another agent, but still we have at least one agent
running, and for no purpose as there is no password to enter...
Or?
Ciprian.
P.S.: Maybe you remember that I've sent a patch in the past that
adds an option to the agent not to double fork (which was rejected)...
I really still strongly believe that double forking is very bad, and
should be done only in exceptional cases... (And the GnuPG or SSH
agents aren't one of those cases...)
More information about the Gnupg-users
mailing list