Tue, Oct 15
Mon, Oct 14
Same here, having YubiKeys and on-disk ssh keys from several computers, it is a bit a pain not to know which key is actually used. Any chances to get at least an update via manual editing of the comment?
Fri, Oct 11
I've also noticed this issue on windows when trying to symlink %APPDATA%\gnupg to $HOME/.gnupg under msys32.
Wed, Oct 9
Sep 9 2019
Sep 6 2019
BTW: I have the problem that I want to know the keys of all cards. "getinfo card_list" along with --demand can be used for this. gpg-card works this way. It does not work if plug in addtional cards becuase card_list shows only the cards for which a SERIALNO command has been used. A new feature to scan the buses for all readers and cards would be quite useful.
Still there are two places where we use "SCD serialno --demand <SERIALNO>". One is g10/skclist.c where we list available keys, another is the funciton card_key_available in agent/command-ssh.c .
By the change of rG9f39e0167d06: agent: Fix ask_for_card to allow a key on multiple cards., the SERIALNO in the stub is just an auxiliary information, not identifying the card. Now, it is the keygrip for key to identify/select the card.
Sep 5 2019
I did too many things at once.
I'm going to divide up into pieces.
Aug 30 2019
Thanks. Fixed in stanble and master.
Aug 29 2019
Aug 23 2019
And also this is excellent point.
The agent is an important part of gnupg and it does not make sense to single out cases when it might not be needed. I can't see any harm from having an agent running. In fact, one of th netxt versions will add yet another daemon which will then be needed in all cases.
Aug 22 2019
Thanks, @gniibe. From reading this patch (i haven't tested it), it looks like it would avoid most unnecessary agent launches (and agent communication) in the (b) case, which is a win over the status quo.
Fixed in master.
This part of code is questionable. It always comes fp!=NULL, so the part should be removed.
If fp==NULL, use of tmpfile is quite questionable because a user can't know where the trace output goes.
I'm going to remove that part.
If it makes sense to warn a user for someone's preference when keys are imported,
here is a patch:
Aug 21 2019
Aug 16 2019
Aug 13 2019
Aug 12 2019
Aug 5 2019
Jul 31 2019
Please see my explanation on gnupg-devel about why the trailing NUL is a source of pain and difficulty for would-be adopters.
Appending a nul byte is fail-safe programming and helps in debugging. It is on purpose and shall not be removed.
Jul 26 2019
Jul 25 2019
Except w32_system function, it's done.
I've just broken out my changes into two commits, one that makes gpg and gpgsm more robust. That should be applicable without any risk.
Jul 24 2019
I've just posted rGb84feb0c82eb to the dkg-fix-T4652 branch, which solves the failure problems by making agent_pkdecrypt and gpgsm_agent_pkdecrypt more robust.
Jul 23 2019
fwiw, this patch appears to cause gpgsm to fail its test suite:
I've just pushed rG1ae16838660a to the dkg-fix-T4652 branch (i just adjusted it the commit message to include the GnuPG-bug-id)
Jul 22 2019