Fixed.

The changes broke saving of groups after editing. See T7181#190402 and T7181#190448. -> T7268: Kleopatra: Existing groups are not saved after editing them

Copying the file to the new location works as proposed in the description, tested with update from 3.2.2 to VS-Desktop-3.2.93.33-Beta

In Debugview I see, after only opening the group configuration dialog:

Good idea. Done for master and gnupg24

Right, thanks for the information. Might I suggest printing a warning when --keyring is given?

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.

I was not expecting a controversy about the reversion as I already said in the weekly on monday that I think we should rather revert that then try to fix it for a 3.2.3 release.

In the keylist of Kleopatra or in the recipient selection of GpgOL we needed to display if the operation with these keys can be VS-NfD compliant or not. I have an encryption subkey which is compliant and aonther one that is not compliant, both are valid. Currently GnuPG will use the "last modified" of the two. And since it is not transparent to Kleopatra which subkey is used, kleopatra could not show "Encrypting to this key is compliant". Which was a requirement. Since we only tell GnuPG the fingerprint of the primary subkey as recipient, to me we would need to either directly add the subkey we want to use as recipient (with ! ) or we cannot really show it. Well maybe with a version check if GnuPG is adding this now.

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

In my opinion it is better to say-> GpgOL does not handle encapsulated mails and don't show anything. Then to now create a new behaviour where something is shown but that something is broken. If we "close" the original "no attachments are shown" issue, do I as a user now have to create a new support issue with "there is a file named rfc822_email.eml shown but it is empty"? So there is another round of communication about this issue while the problem is not solved. This way we can just say that a fix for handling embedded mails in crypto mails did not make it into the 2.5.13 release. Then to create a new state where the feature is broken differently.
Users would then ask themself: If the mail is empty, is it because my mail is somewhat special, etc?

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.

Migrating kleopatragroupsrc to new location worked for update 3.2.2.0 to VS-Desktop-3.2.93.33-Beta on Windows.
kleopatragoupsrc in old location is not deleted, but a copy is written to %APPDATA%/gnupg/kleopatra

Tested with VS-Desktop-3.2.93.33-Beta, works!

Tested with VS-Desktop-3.2.93.33-Beta:

Tested with VS-Desktop-3.2.93.33-Beta, where everything necessary is backported:

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.