The --keyring option is deprecated and does not work at all if the keyboxd is used. This is the default for a new GnuPG 2.4 installation.

Answer in non #dkgmode: Seems I don't need to evaluate the details then. However, excluding auth only keys should be a no-brainer.

Most users are able to read and in particular to answer the question: Do you see the text "rfc822-email"? Try to ask them whether they see a white box somewhere. Nearly impossible w/o a screenshot and even then you get wrong answers. The whole issue is about helping our support people. YMMV

Having a filename even for a bad or empty attachment is a Good Thing™ for the support desk. I also see no regression risk here.

I need to evaluate this. However, what we can can do already now is to ignore all Auth keys - they don't matter at all and it is pretty convenient to have Brainpool primary and encryption subkey but an ed25519 auth subkey on a card. That is because ssh does not support Brainpool. We should show such a key (i.e. Yubikey) as compliant.

Please remove the any configuration file changes from kwatchgnupg. That is not a good idea. Launching kwatchgnupg is
a debugging aid and not a regular operation and thus the user can also enable debugging selectively with kleopatra.
kwatchgnupg should listen on the standard socket socket:// - for Windows we don't yet need it because there we don't have sockets anyway. Or well, eventually we will have same but that requires work in watchgnupg and gpgrt for the logging stuff.

Okay. Let us split it into different tarballs and repos. We will bump the gpgme core version to 2.0 to indicate this split despite that there will be non-ABI/API incompatibility. C++, Qt, Python will then go into separate projects. The old common List stuff will be kept in gpgme core for now. The gpgme core sticks with autoconf stuff but for C++ and Qt cmake style will be used instead.

Okay, I see now that this is US-English and Unicode.

Okay. let me do that for the next library releases.

Thanks.

I like it. BTW, even the unblocking should not be easy to access because users will anyway enter the wrong PUK and then the card is bricked (ready for a factory reset).

I'd say go it it.

Actually we should get rid of stdio functions and use the es_foo replacements from libgpg-error.

Well, backup and restore oddity. I don't think that that we can have a full solution here unless we provide dedicated backup and restore scripts.

FWIW, I received that mail but I hope that this bug is at least fixed with today's fix for T7213. Thus not re-opening.

This patch has a new fix for T5793 which is now only used where needed.

I don't think that we can do much manual testing here because we have all test cases anyway in the regression test suite and our local non-public regression tests (which has the p12 files we are not allowed to publish)

Alright. Done for master; backport will come soon.

Is a solution to this problem by an organization using pass for a log time with quite some users.

Sounds like a good idea.

Please see the quote from Knuth which explains this.

Please name the smartcard tab column Slot and use Smartcard instead of Token. Most users either have a “Smartcard” or a “Yubikey” and they don't known what we mean by “Token”.

Sorry, I can't resist to quote Knuth from his homepage:

Alright: Call gettext_use_utf8 (3) to set the current thread to utf8 and init all new threads to utf8 as well. This function with that value (actually bit 1 is relevant) can be used several times but it will never switch back the initialization to utf8. However, switching back and force to utf8 per threads is still possible.

The garbled data might be due to a bug in dumpasn1 (version 2021-02-12).

Fixing this is important for getting the next release out.