I think that this ticket and https://bugs.debian.org/346241 handle different things, although both do key selection.

This is also https://bugs.debian.org/346241

Implemented in master.

BTW, I just pushed some new features to maste for the gpg-card tool. You can now do

Yes that is fine with me.

Well that is due to "--debug packet" (aka --debug 1). We have this code

With new "KEYINFO" command of scdaemon, finally, we can move on to support better selection of signing key.
(Note: having a private key on multiple cards had already been solved in T4301: Handling multiple subkeys on two SmartCards.)

In master, it has been implemented.

The first "SCD SERIALNO" command let scdaemon re-scan smartcards/tokens.

With new "KEYINFO" command in scdaemon, a list of card keys can be retrieved by:

There is no use cases for $SIGNKEYID.

$ENCRKEYID use case have been removed.

$AUTHKEYID use cases have been removed.

I am wondering if there is any workaround or work in progress about this old ticket.
I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

FWIW, the second listed commit is the right one. You should only look at the STABLE-STABLE-2-2 branch. master and that branch differ; in particular we do not have a cut-off date in master (to be 2.3).

As a user I think that this capability would be a great addition to PGP and it might even make it a standard tool for key generation across cryptocurrencies.

The Name field in GnuPG needs to be at least 5 _bytes_ long. Given that UTF-8 is required for Hangul, a 3 _character_ name is at least 6 bytes long and thus passes gpg check. The Name field is also optional and the whole test can be skipped using --allow-freeform-uid.

Fixed in master and 2.2

Related task: About subkeys is T4028

Prio raised and assigned to werner as he asked for it.

Considering the concrete use case(s), it is more rational to support listing by capability.

Many cards have some printed information and I consider them important to avoid testing one by one all the cards from my pocket.
This I am really in favor of beeing asked to insert the respective card. The new text format private key files make it much easier to maintain this info

In T1287#94619, @werner wrote:

2.1 has the option --unwrap to just this.

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.

I am currently investigating the issue known as CVE-2019-14855 for Debian's LTS version Debian 8 "Jessie" and even Debian 7 "Wheezy".

Regression due to a faulty backport. Fixed in repo; patch is F1052802
Thanks for reporting.

Okay, I can replicate that on gnupg 2.2; it works correct on master.

I am not sure what you want you are going. I see is a verify command using an unknown file or number of files without knowing its content (using globbing (*-SOMETHING) is not a good idea). Some signature is verified okay but it is not known whether the key is trustworthy. You export a ke and then you do a verify on the key - this can't work because a key-file is not a signature.

No bug.

See T4760.

This is a bug tracker and not a general help line. You are better off asking on the gnupg-uisers mailing list.

See also D475.

Without --expert my proposal for full-gen-key would be:

That is due to the mitigation for CVE-2019-14855. I need to see how to find a more specific mitigation.

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?

I've also noticed this issue on windows when trying to symlink %APPDATA%\gnupg to $HOME/.gnupg under msys32.

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.

I did too many things at once.
I'm going to divide up into pieces.

Thanks. Fixed in stanble and master.

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.

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: