The whole TOFU stuff hash not yet been fully translated because there are conceptional problems with the way the code works.

FWIW, --enforce-passphrase-constraints does already work for symmetric-only encryption since 2.2.21 (rGae8b88c635424ef3). Thus this bug is actually a feature request to have a separate set of passphrase constraints option for symmetric-only mode.

The next version will fix the wrong warning and also allow for an empty value.

No, overlapped I/O is not used. OVL is just a zeroed out memory area and thus hHandle is NULL. Errors are of course checked.

Note: menu_backsign can be enhanced to detect such a case in the same way it detects missing backsigs.

Setting to resolved as discussed with Werner

We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.

One bug is fixed in rGdd4fb1c8f668: gpg: Fix first zero-byte case for SOS handling..

Fixed in 2.2 branch.
Also, I found another issue of libgcrypt master, which is fixed in rC361a0588489c: ecc: Handle removed zeros at the beginning for Ed25519..
Further, I found different issue, and created T5116: GnuPG master shows an error when importing Ed25519 keys generated.

I think that it may occur with eddsa secret keys generated with 2.2, too. (In the 50% probability)

Indeed we need to fix/enhance this to make testing of --quick-revoke-sig easier. See over at T5093

I recall that I had the same bug during development. Must have slipped in again - Good catch.

I have added support for this to gpgme (and gpgme++/qgpgme). See T5094.

By the way, --quick-sign-key after --quick-revoke-sig refuses to recertify the key. -> T4584

There is another problem: Even if the first certification was revoked, trying to add a new certification with --quick-sign-key fails because '"user id" was already signed by key ...'

I found a bug. To reproduce generate a new key, then sign it with another key and then try to quick-revoke the signatures. This fails with "Not signed by you."

I forgot that we have LOCK and UNLOCK commands in scdaemon. This was implemented around 2005 but there are no more users in gpg meanwhile.

On purpose. We actually allow user ids and gpg should somehow reflect this. As requested by you I changed it in the man page to what is suggested.

I've noticed an inconsistency between the command arguments in the man page and in the usage/error message.

In short eddsa secret keys generated with current 2.3 can't be imported with 2.2, right? That will lead to a compatibility problem, so we need to fix that in 2.2.

IIUC, it is an issue of GnuPG 2.2.
The condition is where the secret 'd' starts by the first bit = 1 (that is, >= 0x80).
I located the bug in agent/cvt-openpgp.c. The function do_unprotect calls convert_secret_key with skey[1] as usual MPI (not opaque),
and gcry_sexp_build with "(d%m)" will put additional 0x00 at the beginning, which results 33-byte secret in R_KEY. Then, when gcry_pk_testkey is called with R_KEY, when it checks, because 32-byte is expected, it returns GPG_ERR_INV_OBJ. Then, do_unprotect returns GPG_ERR_BAD_PASSPHRASE.

With Debian's GnuPG 2.2.12, I got an error:

With bata1449, I cannot reproduce it.
I can import by gpg --import key-uids-sec.pgp
I tested with Debian's libgcrypt, as well as libgcrypt master (4a50c6b8).

The backend part is ready. Someone(tm) now needs to add it to gpgme. Extending the sign key API might be the best solution.

I was already considering this. I bet some people will view it as a bug if it is possible to add something other than a fingerprint. I'll change it in the man page.

Minor remark: I would change this (in the documentation) to

gpg --quick-revoke-sig fpr fpr-of-signing-key [names]

as for --quick-sign-key, --quick-add-key, and --quick-set-expire, even if USER IDs can be used instead of fingerprints. We shouldn't advertise the usage of USER IDs, if we prefer the users to use the fingerprints. I suggest to also change user-id to fpr in the documentation of --quick-add-uid and --quick-revoke-uid. Using USER IDs for identifying keys is ambiguous and errorprone (e.g. if non-ASCII characters get involved, which, incidentally, is the reason why I started to work on KMail).

I have tested this with Kleopatra. The good news is that SCD GETATTR $DISPSERIALNO now works for the piv app even if the openpgp app is enabled.

Thanks for the info and my apologies for the regression. Please see my comment on T5045.

Unfortunately this new release has a regression affecting users with non-ascii account names. See T5098.

Pushed the change.

I am facing a really similar problem currently in version 3.1.13 (on windows 10)
Although the self-test shows all checks passed. I found out that there is an issue with the cache dir file not being created/loaded.
See:

I am already working on it. The gpg command will be

I missed this one because I only searched for "revoke" ;-)