On 09/21/2012 07:30 PM, MarkB123 wrote:
Thanks. I was able to get it to work using the --batch command.
Wow, that contradicts advice I received here recently. Thanks for
reporting back.
John
Hauke Laging wrote:
Am Fr 21.09.2012, 10:33:05 schrieb John Morris:
Gnupg2 won't
Gnupg2 won't read the password from a fd. You must use a gpg-agent.
You can get the expected behavior from gnupg v. 1.
John
On 09/18/2012 11:25 PM, Mark Brownlee wrote:
echo MyPasword1432!|C:\Program Files\GNU\GnuPG\gpg2.exe
--passphrase-fd 0 --homedir
Hi Werner, glad to hear from you.
On 09/14/2012 10:46 AM, Werner Koch wrote:
On Sat, 8 Sep 2012 19:09, j...@zultron.com said:
I'm pretty sure now that this is correct: gpg2 password input cannot
be captured without the use of a gpg-agent.
That is right. gpg2 conceptional does not know
On 09/10/2012 04:55 PM, Robert J. Hansen wrote:
Second, no, of course the distro-on-a-stick doesn't defend against Van
Eck phreaking.
Distro-on-a-stick doesn't defend against anything if you don't trust the
hardware, which you shouldn't if you don't trust the software. It's
entirely
Hi list,
I believe I've figured out the bigger problem.
Partly, yes.
AFAICT, the '/usr/bin/gpg' distributed with gnupg v.2 is still not
binary compatible with the same from gnupg v.1, and gpgme does not know
how to feed it a password using a passphrase_cb.
I finally hacked around the
Hi list,
I believe I've figured out the bigger problem.
On 09/07/2012 08:23 PM, John Morris wrote:
I still have not found a case where passphrase_cb is actually used. In
the gpg2 manpage, the description of the '--{no-}use-agent' options
indicate that the gpg agent is *always* used, which
, and there is no gpg-agent configured
capable of supplying the passphrase.
All the above seems to be true, and yet the application I'm having
trouble with (sigul) was working well a couple of months ago. Can
anyone confirm or deny the above?
Thanks-
John
On 09/06/2012 06:34 PM, John Morris wrote
Hi,
I'm having trouble with passphrase_cb seemingly being ignored. The
GPG_AGENT_INFO environment variable is unset.
It could be similar to this bug here, and I am indeed using pygpgme:
https://bugs.launchpad.net/pygpgme/+bug/49
Can someone eyeball this trace and see if anything obvious
