Wed, May 27
Mar 5 2020
I t could print a warning for a non-existant homedir
Sure, I personally know that GnuPG requires a homedir to operate.
As you surely known GnuPG requires its home directory; in particular when using the gpgconf to manage the config options. Thus I can't see what to do other than error out. gpgconf needs to know the location of the config file; if it is containign diretcory is not existant it will fail anyway.
Mar 4 2020
Jan 13 2020
Dec 17 2019
The description comes from gpg/gpgsm while the prompts are from gpg-agent. Thus if the agent has been started with the German local but gpgsm without a local this would explain the behaviour.
Dec 12 2019
Although I don't use the ssh client on Windows I had to integrate the Windows ssh server into our release process (GlobalSign sent us a Windows-only token, for the new cert and so we can't anymore use osslsigncode). The ssh server is really stable and so it makes a lot of sense to better integrate our ssh-agent into Windows.
Dec 5 2019
My analysis is that it's not a race condition but... it's about secure memory.
It is true that we have a race condition between putting an entry to cache after pinentry interaction _and_ next examining cache to invoke pinentry. But for this test case, the gpg process of unlock the key (and cache the passphrase) is finished before running the run-threaded command.
Dec 4 2019
That is actually a GnuPG thing. We originally did it this way to help people remember their passphrase before they start using the key. I agree it is annoying and I would like to remove it too. At the same time we should really think about making no-passphrase the default and require it only with certain compliance settings.
Sep 27 2019
OK, I identify the problem.
Sep 9 2019
But this problem remains for several versions for some time. I tried to find out the source of this "new option" in the communication, but I could not find anything about "GPG Agent" in the source code of openssh.
Sorry for the late answer, but I have been busy. Actually this happened against several ssh versions, for some time now.
Aug 20 2019
It was fixed in GnuPG master by rGc395f8315362: agent: Terminate pinentry process gracefully, by watching socket. and rG374a0775546b: agent: Close a dialog cleanly when gpg/ssh is killed for CONFIRM..
Those will be in GnuPG 2.3.
This appears to be https://bugs.debian.org/850946 and it does not appear to be fixed to me.
Aug 2 2019
Jul 31 2019
Please update the documentation for the function in that case.
No, it was not in mind. I introduced this only for backward compatibility. It will be extended iff we have a need for it.
Jul 30 2019
My understanding is: it was introduced by rG370f841a0135: Enhanced last patch. in 2009 to give information to client (for a specific command at that time), possibly in a hope that server side would support the feature for all commands (and client could benefits).
Jul 29 2019
Jul 11 2019
Which SSH client are you using?
gpg-agent side is fixed to relax the error handling.
Jul 9 2019
Jul 1 2019
As I said we do this with all GnuPG components. Pinentry is a bit of exception because it is an external package.
I have also had bug reports which later turned out that a wrong pinentry was used; I prefer to know eactly which pinentry is used. Regarding your concrete problem I suggested to add a note with the full name of the pinentry or to change the error message to something better understandable.
So this is a defense against an adversary capable of creating a pinentry-wrapper somewhere in $PATH, but not capable of modifying gpg-agent.conf? It sounds to me like this is a defense against a very unusually-constrained attacker, at the expense of regular, common bug reports and user confusion.
GnuPG invokes its components always with their absolute file name. We want to mitigate attacks where malware creates a pinentry wrapper somewhere in an improper set PATH.
Jun 27 2019
Jun 25 2019
I'm unlikely to put a windows-specific patch into the debian source, as
i have no good way of testing it, and it wouldn't affect any binary that
Jun 24 2019
@dkg, for your patch, it can be improved for Windows by using its event mechanism. You can see gnupg/scd/scdaemon.c.
Hm, T4521 suggests that the two different cases should not be treated differently. If you think that they *should* cause distinct behavior, please do mention it over there!
There are two different cases: (1) By SIGTERM and (2) By KILLAGENT. It's true that the agent stops accepting on the listening socket for (1), but it's not the case for (2).
This particular problem is for the case (2).
Jun 21 2019
@gniibe, thanks for the diagnosis! I agree that restarting or shutting down the backends should be done in the reverse order as a simple workaround.
Correct solution is to implement KILLAGENT synchronously, but it's somehow harder to implement.
Easier workaround is modifying gpgconf like: