Another customer case with "always show security-dialog" on (-> external resolver):

I have analyzed this. In the ribbon we get a mailitem OOM object as reference, but that can be a different pointer then the one we used for decryption / verification. Our trick for this was to assign mailitems a custom uuid property and then look for that from the riboon pointer so that we can update accoringly with our internal Mail object representation.

Changed the task description to easier find it

Ok. Thanks for testing. That confirms my suspicion. rOdd3ff8397aaf62e58fa9405ddc5397cb6bcfdc29 is to blame here with the setReadFlag line as the specific cause. Because it is intended to trigger a save back. The problem was that we had circumstances where other addins changed the mail and really wanted it to be saved back to the server. So we call "save" before decrypting the mail to ensure that these changes are saved and then we decrypt, put in our temporary plaintext and ensure that the plaintext never is saved.

I testet it with 4.10 and GggOL 2.5.6. The file isn't changed if I open it. So it seems the change happend in 4.2.0.

Do you know if this is something new that started to happen with 4.2.0 for the first time or did it happen with 4.1.0, too?

Not really, the GnuPG System configuration settings are generated from gpgconf output and there is no tooltip mechanism for that.

we could include the "better explanation" part, though. The options in "GnuPG system (technical)" do not have a tooltip, we could add one there, at least.

This won't go into the next release it is too invasive and needs to be very thought through and announced to users. This also needs to be deployed in a Gpg4win first to get user feedback. GpgOL is pretty much done for the summer release of GnuPG VS-Desktop.

I am reopening this at least for testing as we have reports that another client is facing the issue with recent versions and also with verified mails .

This fix was pretty minimal and I could test:

This works now for me and all the examples I have for the customer. With https://dev.gnupg.org/rO0fc4b87a946dd634d4b61d4e8cb0ad6164faa83c it looks to me in KMail like KMime might handle the transition between different encodings / languages not correctly in continued parameters.

I won't go so far to try to fully implement RFC2231 in the rfc822parse. But I have an idea how to implement this in a secure and robust manner in rfc822parse without touching the parser or the token stuff. My idea is to treat them as seperate TOKEN and then combine them in query parameter just for name and filename values.

I found the rfc https://datatracker.ietf.org/doc/html/rfc2231.html the code to decode this is not fun and can be found here: https://invent.kde.org/frameworks/kcodecs/-/blob/master/src/kcodecsqp.cpp

Hi Carl,
yes I saw that test case. Btw. I don't really think that this comes from Outlook itself otherwise I would have seen this much earlier, the current MIME Parser in our Outlook Plugin is about 8 years old. Currently this comes through some kind of AppleMail (server?) application to the customer.

To be honest I have never seen such a way to transfer parameters but KMime and our new MIMETreeparser in T6199 can probably handle them but our old and trusty RFC822parse code in GpgOL needs to be adjusted.

Fix pushed to the 23/07 branch and master.

I am raising this up from the wishlist. Error messages from CRL errors can be so obscure, like we just had in a support call.

I noticed this recently, too. Should be fixed. Especially if we want to use this in KMail, too.

No, it doesn't do even that. Sorry, I only tested that with 3.1.26 which is older than your fix.
No encrypt-only key is offered or selectable for signing any more in Gpg4win-4.2.0-beta360

I don't think that Kleopatra allows to select an encrypt-only key for signing because I have fixed exactly this issue a couple of months: T6456: Kleopatra: Offers encryption-only OpenPGP keys as signing key.

This works, when sign is selected and no standard OpenPGP key for the mail address exists.

This will not translate into the new addon and is too large a change for the current one.

This no longer happens. It was a case of such inline signature images. Maybe if they are added through the clipboard they dont get a filename or something like that.

Works good enough for me

Fixed with: 8e258f77114ce0474a2bb6aa1314385e2fb68e15

With the recent commit the old workaround works reliably again.

In current Kontact and now also in Kleopatra, by default, it's 30 days for own certificates and 14 days for all other certificates (including certificates in issuer chains), but Kleopatra currently doesn't notify the user about expiring issuer certificates.

The default time period for warning about pubkey expiration is 14 days in the old Kontact (IIRC).

Good timing. We have just added the necessary bits to the shared libkleopatra. They just need to be used in GpgOL. See T6330: Kleopatra: Additional Expiry handling.

works, a key with a revoked uid is accepted as VS-NfD compliant, VS-Desktop-3.1.27.0-beta44

works

Hint: When the user disabled GpgOL -> Automation -> Automatically secure messages in the configuration of GpgOL he could see the email body again.

I am downgrading this to wishlist. Even though I had worked on this a lot the regression risk is probably too high to fix this before GpgOL becomes obsolete.

Hier is a log file from GpgOL (+Code verfolgung)

I have seen that the rule is honoring the exclusions of Microsoft Defender but I do not know if one would need to exclude gpgol.dll or the gpgolconfig.exe / gpg.exe in this case. https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide#microsoft-defender-antivirus-exclusions-and-asr-rules

Gpg4win 4.1.0 comes a slighly newer gpgol which should be tried before we continue. Set to low prioprity because this seems not to be easily reproducible.

The gpgme part has been done. Some minor changes in Kleopatra regarding the VERSION file checking would be useful.

As discussed with Werner, the initial default will be changed "guessed" in GPGME to avoid code duplication between libkleo and GPGME.

This should really be in the next release.

Putting up for grabs and removing Kleopatra tag since for Kleopatra users this has been fixed (unless they manage to trigger multiple separate concurrent imports in Kleopatra).

Hello Andre Heinecke,

I'm that user - only thing I can think of really is that I used the tool "O&O ShutUp10++" to restrict Win10 Settings. During the troubleshooting I reverted to the standard settings, but it made not difference.

As I assume that many people have HTML emails still turned on, and have no crashes, there probably are more conditions that have to be met to trigger this crash.