--auto-key-retrieves tries to find a key when verifying a signature. --locate-key however does the same as what -r does and locates a key for further use. If you don't what that, don't include a key discovery mechanism in the the auto-key-locate like (wkd in this case, which is anyway the default).

Thanks for your info.

I will be using OpenPGP applet for the YubiKey NEO in a virtialized vanilla Debian environment. This emulated card can sign new keys just as correctly. PINs are the default 12345678 for admin and 123456 for user.

Or your card has the key to certify and its fingerprint is: CB522FE0379DDF40A93400D7E4BC91FACDA9A65B

Simply, we need the output of gpg --card-status to identify which key is on your card.

Nope, that's all I had. I'll try to get some debugging info in an hour.

Please show us your card information. Does it have unrelated signing key?

I'm pretty sure. That's the actual output above. Once again, if I remove the smart card, gpg --clearsign starts to just work, without a need to specify --default-key.

Are you sure that you have only one secret key? (run: gpg -K)

Wald certificate will be fixed very soon. But as it is not fixed yet, I provided an http link, not https for you.

Thomas, please provide a sample certificate. I can't access the intevation site to see whether one of the links has the cert. And pretty please fix the wald certificates!

Documentation for the regular expression of Jim Tcl: http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html#_jim_built_in_regular_expressions

Created gniibe/regexp branch.

RFC4880 (and older version of RFC2440) referes Henry Spenser's REGEXP. There are three implementations: https://garyhouston.github.io/regex/

Am I right as to this being due date?

That looks pretty much like another gawk regression. The easiest fix is to install another AWK version (e.g. mawk).

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.