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).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 21 2019
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.
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.
Jan 26 2019
Jan 25 2019
Since there is --mode=normal option, it should be --mode=ssh.
Jan 23 2019
Jan 21 2019
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.
Jan 17 2019
Jan 11 2019
Jan 5 2019
Right. We won't change that though. Sorry.
Jan 4 2019
Dec 20 2018
Dec 19 2018
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.
Dec 18 2018
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/.
Dec 17 2018
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.
How scdaemon responds when there is no card available?
In Wald someone reports that this also appears to happen when decrypting. https://wald.intevation.org/forum/message.php?msg_id=6377 Probably run-threaded will help to flush this out.
It became common, because many people now use larger keys.
For RSA-4096, three simultaneous connections for decryption may cause the failure.
In the experimental patch of D472: Limit active connections for gpg-agent, I limit gpg-agent to accept two connections only.
Dec 16 2018
Agreed this looks like it should be made default behavior. This has affected many people I work with, and even with searching, this ticket never came up. I only found out about it by making a ticket myself. This issue looks like it has generated at least 3 tickets in this bug tracker, and the agent is raising memory errors during normal usage, which still smells like a bug to me.
Dec 14 2018
Dec 13 2018
Dec 12 2018
Uhm, if this option is useful why isn't it default behavior?
The --auto-expand-secmem option is available in 2.2. and master for quite some time. It works if libgcrypt 1.8.2 or newer is used.
Not a bug :-). I should have read my own docs before starting a long debug session. The things is that the auto expanding of the secmem area is only done for xmalloc_secure and the internal MPI allocation functions. It is not dne for any memory which is allocated with xtrymalloc becuase those properly return an error to the caller. The idea is that if the caller wants to get an error back he has also the assurance that them memory is allocated in the non-swappable memory (i.e. not in the expanded parts of the secmem).
For my case, with $GNUPGHOME/gpg-agent.conf having debug-all, I observed that rsa_decrypt failes with 'Cannot allocate memory', after debug output of 'res'.
Reading libgcrypt/cipher/rsa.c, it is line 1439, where it calls sexp_build (MPI of PLAIN into SEXP of R_PLAIN).
I think that it does indeed memory failure here.
Having "auto-expand-secmem" in gpg-agent.conf, it goes well.
Dec 11 2018
I can easily replicate this; it is a problem somewhere in the secure memory code of Libgcrypt.
Dec 3 2018
Nov 30 2018
..... And now after looking into this a bit deeper after attempting to build gpg-agent for windows, it appears that this is a bit deeper than the logic above (which is actually sound, when I read it for the second time)