gpgtar is compatible to PGP Desktop's format which they call ZIP. This is technically ustar with the most common extensions. Don't let us go into yet another TAR format discussion.

Also added a new gpgme context flag "proc-all-sigs" and a --porc-all-sigs option to gpgme's run-verify.c tool.

Btw. GpgOL also parses the mail as having a bad signature. Also gpgparsemail from gnupg. I wonder if the creation side of that mail is broken or the verification code. :)

My recommendation would be to include this change together with the other changes from today even in a minor release since any changes are behind:

I tested all scenarios I could think of with multiple embedded mails and mails which had themself embedded mails. signed, unsigned, s/mime and openpgp.

This is caused by "Mail::removeOurAttachments_o()" to avoid that when you forward an encrypted mail, that the decrypted attachments are also attached as well as the original mail. Same goes for send again.

Implemented in https://invent.kde.org/pim/libkleo/-/merge_requests/130 and https://invent.kde.org/pim/kleopatra/-/merge_requests/275.

The new option `--proc-all-sigs' will be available in 2.5.1, 2.4.6, and 2.2.45.

I can reproduce

I have opened T7268: Kleopatra: Existing groups are not saved after editing them for the issue that was found while testing this ticket. The issue is a regression caused by changes made for T7233: Kleopatra: Certificate details dialog non-interactible when opened from group edit dialog.

Backported for VSD 3.3

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