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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 4 2020
Jan 13 2020
Dec 17 2019
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
we ship.
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:
I found a race condition between KILLAGENT command and accepting another request.
Here is a patch to replicate the race condition :
Jun 4 2019
May 29 2019
May 28 2019
I also tried adding this to my gpg-agent.conf file:
Oh, in case it wasn't clear, the idea that another application (GNU emacs) is receiving keystrokes meant for the gpg-agent prompt is probably a security risk....
May 23 2019
Simply sending "KILLSCD" is implemented.
May 21 2019
Also fixed for 2.2
The behaviour related to ssh key access is due to the way ssh works: After a connection has been established to a server ssh presents to to the server all identities (public keys) it has access to (meaning it has a corresponding private key). Thus we can't tell ssh all the keys we have because that would be an information leak and may also take too long. Because the user may in some cases not want to use the ssh-agent but resort to ssh command line input of the passphrase, we do not insist on using a key known by gpg-agent.
I located the bug in agent/command-ssh.c.
Our practice is two calls of gcry_sexp_sprint; One to determine the length including last NUL byte, and another to actually fills the buffer.
The first call return +1 for NUL byte.
The second call fills NUL at the end, but returns +0 length (length sans last NUL).
I spent a lot of time trying to figure out how to automate the interface between my preferred password store (gnome-keyring, via libsecret), but with the loopback pinentry mode changes in gpg 2.1, it is much harder (if not impossible) to do. Having passphrase caching is the only thing preventing me from choosing a weaker passphrase on my gpg keyring.
Disallowing passphrase caching is likely to have the unintended consequence of users choosing weaker passphrases that are more easily memorized and/or typed. Caching should be permitted, IMO. This puts more decisions about passphrase management into the control of the user.
May 20 2019
And yet, that interface is already being used by the agent-transfer utility in monkeysphere. The interface exists, it is not marked in any way as unusable or deprecated or off-limits, so it is used.
That is on purpose. Exporting of a secret key should in theory not be possible at all via gpg. In practice we need a way to export a key, but that should be the exception and thus we do not want any caches for passphrases to have an effect.
trigger what command? i'm pretty sure gpgconf --reload gpg-agent does not trigger updatestartuptty. And it should not do so, afaict -- if you think it should, i'd be interested in hearing the rationale for it.
Does gpgconf --reload gpg-agent trigger that command? that's the ExecReload setting in the systemd service unit I'm looking at.
May 19 2019
This doesn't sound systemd-specific to me, fwiw, though i don't understand how to reproduce the problem from the given description here.
May 15 2019
May 12 2019
I often put an extra nul byte at the end of binary data so that accidental printing the data (e.g. in gdb) assures that there is a string terminator. But right, it should not go out to a file.
May 8 2019
As this update lists multiple issues and following fixes for them, maybe it was resolved by Microsoft?
Apr 29 2019
Since 2.1 the standard use of gpg-agent is to have it started on demand by the components which require it. The use of
"gpg-agent --daemon /bin/sh " should be used for debugging only.
I've applied your patch with an additional comment to our master branch. Thanks!
Apr 5 2019
I did lot of tests in the last weeks while working on gpg-card.
Mar 27 2019
Sorry, this did not make it into 3.1.6. But I'll definitely see about it for the next release. If it is an institutional / corporate issue you could also contract us through www.gnupg.com
Mar 26 2019
In T4427#123774, @werner wrote:Can you please run
gpg --debug ipc -vKwhich will also start gpg-agent and print some diagnostics. You may want to redact the output. You can also run
From: aheinecke (Andre Heinecke)
Sent: Montag, 28. Januar 2019 19:25
fwiw. Your patch is beautiful in which it follows our coding style and
debug output. I'm confident that we will accept it but currently I have
to read up on Job's a bit.
Is there a way I could help you with this? This issue is hampering adoption
of GnuPG 2 here.
--
Jan Echternach
Trying to install the update manually (according to windows update my windows is fully updated) it says "This update is not meant for your computer" and aborts.
Can you please run
gpg --debug ipc -vK
which will also start gpg-agent and print some diagnostics. You may want to redact the output. You can also run
gpg-agent -v --daemon
which should also print some more info.
Mar 18 2019
Mar 6 2019
Thanks for fixing that.
That's my badness. In wait_child_thread, assuan_release may cause thread context switch to agent_reset_scd which accesses scd_local_list; This access should be serialized.
And... in start_scd, calling unlock_scd should be after unlocking start_scd_lock.
Feb 26 2019
Does not happen in 2.2. Additional requirement to test this bug in master: Another connection to the scdaemon must be open. For example running scute or, easier, call "gpg --card-edit" and keep it open.
Feb 19 2019
Fixed in master.
Your problem is apparently not an issue of upstream development of GnuPG; It is your setup script (agent.sh?) which specifies /dev/shm/SOMETHING.
Standard GnuPG never does that. We have no idea about use of /dev/shm/SOMETHING.
Jan 28 2019
fwiw. Your patch is beautiful in which it follows our coding style and debug output. I'm confident that we will accept it but currently I have to read up on Job's a bit.
That is a very interesting problem that we did not have on our radar.