gpgme has a disabled flag (only set on the primary key) and taken from the --wwth-colon listing where it is the 'D' in the usage.

Here comes a new test key along with its 3 secret parts (one for the primary and two for the composite Kyber subkey).

Wit the test keys posted in T7014 it is now possible to decrypt the sample data. The test data has been slightly adjusted for the new format; see

Revocations are an exceptional task and rarely needed. In this case ("help, help , my key is compromised, what shall I do now?") an extra dialog to help the user is imho appropriate. This different for the key generation process, becuase this needs to be done by every user at least once and thus should be UI-wise as simple as possible.

This is a KDE bug and not really appropriate for this tracker.

Yellow indicates a warning. In the old days we used yellow in too many cases and people barely got a green. This raised more user questioned than it was helpful. There is also a problem with accessibility if we overload colors too much.

I guess the agent was still running when you deleted and soon re-created the ~/.gnupg directory. The agent is responsible for the private keys subdir and it did not yet noticed that its homedir (and thie subdir) vanished. Depending on your system the agent should terminate itself after some time in case the homedirectory was deleted. Thus to remove the homedir please use

I created a pubkey (actually a subkey) for your above test keys:

I don't see a problem here. Of course Kleopatra could run a gpgconf -K all when it really exits but I doubt that we need to do that in this special elevated case

Pretty obvious. RENC is an allowed usage for an RSA key and thus set in the mask. I restricted this but allowed to set it anyway when using the "=sr" shortcut (here to set as signing and R-enc). Thanks for reporting.

This is long known and we won't fix this for gpg4win.

Please use

Tobias, if you find some time, can you please see how this can be done.

Please keep also in mind that the OpenPGP card specification has always and is still developed along with GnuPG . Thus if there are any uncertainties in the specification GnuPG's way of handling thing is the way to go. If there is a way to chnage things without risking any breakage we can of course fix that. In all other cases we need to continue wit the current way. For larger changes in the spec we can of course cleanup stuff - Achim is currently reworking on a revision.

Works for me using the latest vsd beta (3.1.92.39)

I am still not sure why I noticed the double signing but with the new stamp feature we have an effective way to avoid long delays due to authenticode signing. Some gmake macro guru might want to look at gpg4win.mk.in to get rid of the duplicate rule ignore messages.