When I last talked about this ticket I had not thought of the fact that we need to have this in some kleowrap wrapper and that currently stdout and stderr are not printed in a process which forwards its call an already running kleopatra.

I thought about this and any change here has a regression risk and the release is already overdue. If we change this now as a band aid before a release with keyboxd we really need this only for one release.

Regardless of the migration. At least we need to set GNUPGHOME early in Kleopatras main to the value returned by GpgME so that the qt.conf patch works in KF6.

I see no commits that change the behaviour or do the migration. Then this is not fixed. To clarify. For me this issue is about General config files of KDE / Qt. Not only about the kleopatragroupsrc Since the kleopatragroupsrc was fixed in the last release already.
In the state I left it for VSD 3.3 (master) qt.conf is only written for Gpg4win. And not for VS-Desktop. So testing with Gpg4win has different results. This was the underlying reason since qt.conf was written with FileWrite and not packaged. I only changed that in Gpg4win master.

The problem is that this is a just a band aid at best. The underlying problem that shows up in other places is not fixed. We should apply the band aid only if we say we don't fix the underlying problem.

Either this has super high priority or we fix S/MIME keylistings in GnuPG. I will write a mail with details as that involves customer information.

String values are stored as UTF-16, but might not even contain a terminating doublezero since it can be any binary data. Note that on Windows the registry can be used to set environment variables. There "Edit binary data" shows exactly what is in the regkey. So if you use regedit with the String functions you can see that they are converted from latin1 to UTF-16.

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.

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.

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?

Just thinking about this, we have at least one customer configuration that uses KXMLGui to hide all smartcard actions and the view. And one other that disables certify actions everywhere. We need to check that this still works with the new details view.

Without administrator rights it does not work for me, since it then cannot write to %PROGRAMDATA% to install the VS-NfD mode config files. But the only thing for "does not work anyway" that I know and could quickly see is that "IPC connect call failed" problem with GPGEX (which we are planning to remove / replace anyway). So I don't think it is very important to remove this and addtionally we do not know if this is something that is used, we have offered it from the beginning but have no data if our customers use it. We can suspect that we would have seen more support questions about the gpgex error if it was widely used. But I always thought that the "only for me" installation option was useful for some use cases.

I think the executables also use the same values for translation.

I would say this could be treated as a duplicate or subtask of T7147: Kleopatra: Add debug information / Log handling KWatchGnuPG is in my opinion not very useful, since as a developer debugging things the command line and "watchgnupg" without the K are more then enough, KWatchGnuPG is basically just a qprocess output viewer of watchgnupg. IMO it would be similar if we would just execute CMD or Konsole with "watchgnupg" and show that window. Logging to a socket has the advantage that the entries are displayed in the order they come in while with files there is an issue of io synchronization and not all components can log in the same file. But you could use same QProcess / watchgnupg to "sync" the log entires and then write them to a file.

The whole problem that we now had to take care of marking mails as Read was a misunderstanding of the code. As I assumed since we saved the mail. The property change of "UnRead" would then not be synced to the server, but more testing and user feedback after the last release has shown that the even FC99 which we observed in the "Uncancellable write event" cases was sent to us in conjunction with the property change of UnRead.

This is another side effect of: dd3ff8397aaf62e58fa9405ddc5397cb6bcfdc29 and 1f9c757872b033e1be8199c4d488ac84bf8f07bd before that revision the code that changed IPM.Note.GpgOL.MultipartSigned to IPM.Note.SMIME.MultipartSigned was only executed for S/MIME mails. I do now understand that the code in question at the beginning of decryptVerify_o was meant for other Addins, Outlook Web Interface etc. to ensure that the message class on the server was always IPM.Note.SMIME and not some GpgOL specific class so that outlook or other tools like securePIM would still treat the mail as S/MIME.

This is not a distinct issue from T7242 but the same.

I went for the placeholder text because you asked what should be shown on error. And I would rather not follow your suggestion and show an empty widget but keep the placeholder text then.