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.

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.

@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).

@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 :

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....

Simply sending "KILLSCD" is implemented.

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.

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.

This doesn't sound systemd-specific to me, fwiw, though i don't understand how to reproduce the problem from the given description here.

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.

As this update lists multiple issues and following fixes for them, maybe it was resolved by Microsoft?

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!

I did lot of tests in the last weeks while working on gpg-card.

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

In T4427#123774, @werner wrote:

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

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.

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.

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.

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.

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.

When bogus entry is "", the error is GPG_ERR_NO_PASSPHRASE, and user cannot input the passphrase.

Confirmed that manually created entry in gnome-keyring-daemon causes trouble.

Since there is --mode=normal option, it should be --mode=ssh.

I've developed a simple patch that sets the CREATE_BREAKAWAY_FROM_JOB flag when creating a new background process. This flag requires a special permission on the job object, which is tested first. This means that the patch only works if the parent process sets JOB_OBJECT_LIMIT_BREAKAWAY_OK on the job object, otherwise the behavior should be as without the patch.

Right. We won't change that though. Sorry.

FWIW, the canonical way to make sure that gpg-agent has been started is to run

You're very welcome. In my instance, this is "resolved" - I now get the prompt I realised I needed so to me this bug could be considered closed or wontfix, but I'll leave you to do with it as you please.

Basically, you are right. In addition, gpg-agent asks scdaemon about list of card/token.

OK - so if an entry is not required in sshcontrol for a smart-card key - is the private key stub sufficiently detailed enough for the agent to realise that it can ask for that card to be inserted for an ssh connection?

sshcontrol entry is required for non-smartcard keys, but not for keys on smartcard. This is intentional. For gpg-agent and current format, it is only the information for gpg-agent to know if a key is for SSH or not.

Also - going back to sshcontrol - with an ssh key added to the agent with ssh-add, an entry in sshcontrol is required - but not for a key on a smartcard. Is that intentional, or just a byproduct of the smartcard diversion that happens?

Oh, wow - yes, adding to sshcontrol brings up the prompt - I do however need to stop the agent from being restarted on insertion for it to subsequently ask for the unlock.

I see your point. You are right. For SSH access, it just fails without asking insertion. It's not Windows specific.
I checked the change of history of gpg-agent, but I cannot find prompting insertion was supported.
So, I don't thin this is a regression.

Yes, it's running. I have a scheduled task that spawns a vbscript to ensure that gpg-agent is started on login, and restarts it on insertion of a card (specifically for two reasons: windows ssh clients don't typically start agents automatically, and windows can cause gpg-agent to get a but upset after a card is removed and re-inserted. Edit: although, I think that latter reason might be resolved now... I haven't investigated deeply. more info here and here).

Thanks for your information.
Hum, you are using gpg-agent for SSH access.

When no card is inserted, usage of an ssh client simply fails to request insertion of the card for the stub keys present in ~/.gnupg/.

Asked to raise the priority on this. The quality bar issue is T2103

Please let us know the version of GnuPG, the output of gpg --card-status when inserted, and how gpg is not working well, etc.