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.

In T7018#190062, @ebo wrote:

Suggestion for the "placeholder" screen:
Only show "Please insert a compatible smartcard." And then below: "Known supported smartcards are listed at https://gnupg.com/kb/smartcards.html".

Mh, in the past I would have thought that drag & drop might be worth it for the use case of browsers where you sometimes need to have your key as a text representation. That was originally the Use Case that stood behind the "Text export" in Kleopatra -> Details -> Export. But nowadays I feel that every text box I write into in browsers somehow supports also to drag a file in there for uploading. Or related I sometimes paste image data directly to phabricator and it is attached as a file. And if browsers can handle that, maybe we are even better suited if we would just export it as application/pgp-keys ? But I can't really specify that as I would develop this myself by trying some mime types on windows and see how the relevant software -> Windows Explorer, Outlook, Browser and maybe some other Office software handles that mime type.

I tested it doesnt seem to work reliably on windows, it always exports into my home folder regardless of where I drag and drop in explorer or on the desktop window. The drop also seems to require an additional click while it usually works on windows on release and in Outlook it was inserted as a text block and not as a file attachment. Also, but that might be specific to the broken dev installation i have right now it seems to keep handles to the exported files open so I can't delete them or move them right after.

Help -> Additional Documentation -> GnuPG Commandline now brings up the GnuPG Manual in the browser for Gpg4win. This solves the issue that this menu entry (Additional Documentation) existed in Gpg4win and Kleopatra on general Linux but was empty. And the API does exist now to add more entries easily if suggested. I just checked on Linux in master and it worked for me.

While searching for a different issue I found T6512: keyboxd with data pipe in which as I understand it a keyboxd hang is fixed but the fix in that task is not part of the stable branch and only in master. I might be misunderstanding it but just from reading the comments in T6512 this might be related.

This issue can be resolved in my opinion, as I have tested the 64 bit installer and tested a 64 bit pg4win. The current status of this is that we don't want to have different library names depending on the architecture since it is installed in the same way as linux in different directories. So there is nothing left to do here.

My suspiction with this is that here the exchange server / outlook parses the mail attachment into MAPI and somehow handles mails differently then other attachments. This automatic conversion regarding attached mails is why we always ask users in Support to send us a problematic mail as a file in a zip archive. Otherwise Exchange will convert an attached Outlook MAPI mail to MIME and on the receiving side we can no longer see the original strucutre. Similar things are probably happening on the receiving side where the MIME eml "file" is converted into a MAPIOBJECT holding the forwarded mail which then confuses our internal knowledge about the attachments causing this error.

This works now.

I tested it and updated the community wiki documentation to refer to it.

I am observing strange beavior on WIndows 10 22h2 and OL 16.0.17830.200056 even if no mail is displayed in the reading pane and the selection returns no selected mails, Outlook loads mails which are e.g. right clicked. I think a way which could prevent some problems and allow it again to change flags and categories for unselected mails would be for us to check in the Read event if the mail has some inspector and abort in that case. This could also increase compatibility with other addins. I will do some experiments with it.

Well for 3.3 we will have full support for high contrast with the correct icons on all platforms, additionally we detect and support dark mode on all Windows 10 Versions > 1709 So this can be resolved. (Both for Qt5 and 6). What I have not yet checked if Qt6::systemInfo::colorScheme reports the correct one under windows 11 desert theme, but as you mention that is also part of a different issue where when then also should clean up the kleo systeminfo etc. if this is reliably supplied as information by qt.

Well, my hope for this was some kind of Format where we keep the keys + the signature together with encrypted files. Because I think it is an extremely common usecase to decrypt a file, modify it and then to reencrypt it to the recipients that it was encrypted to before and I think it would be a good usability improvement if after decryption, when a file is then encrypted again Kleopatra would have the recipient dialog prefilled with the original recipients. T6564: Kleopatra: Re-encrypt an encrypted folder to the original recpients And for Gpgpass this could be used in exactly the same manner just with a diffrent UI and focused on folders with multiple files.