Key creation problem with 2.1.16
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Dec 6 17:51:58 CET 2016
Hi Carola--
On Tue 2016-12-06 07:41:20 -0500, Carola Grunwald wrote:
> I'v attached my application's complete log of the 'gpg.exe' program call
> including the command line string ('Application' + ' ' + 'ExeStr') with
> the 'Environment' parameter(s) set.
ok, but it felt a bit like "burying the lede" in your attachments --
it's a lot easier to understand what's going on if you describe it
clearly at the top of your message.
that may be one of the reasons it took nearly a week for anyone to
respond to your message.
now let's see if we can solve this!
> It's not necessarily a problem with the GenKey code but may rather point
> to an unreliable gpg - agent IPC, which, as gpg starts a new agent
> instance minutes after processing begins to fail, would also explain the
> many orphaned gpg-agent.exe entries in my Task Manager's Processes list.
it would be great to see some logs for the gpg-agent processes -- if
they're dying or becoming zombiefied, what were they doing when that
happened?
if the IPC is flakey, where is it failing?
the main difference between your two logs seems to be that the agent in
the failed case is actually asking gpg for a passphrase, whereas it
*wasn't* asking gpg for a passphrase in the successful case.
what would cause the agent to behave differently like that, given that
it had already done INQUIRE NEWPASSWD ? do you think the agent died and
a new agent started up, which hadn't cached the previous password?
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20161206/6f2d0e5d/attachment-0001.sig>
More information about the Gnupg-devel
mailing list