I'm quite sure, that I have seen this multiple times on current versions. Not sure, if one could send it again, I think at least the body is empty.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Fri, Dec 12
Thu, Nov 27
Additionally to the issue Andre cited years ago, we also did some changes to fix other how signed/encrypted mails are shown, which are also relevant for the inbox. This should be fixed.
This is a duplicate of T7833: GpgOL: Security level 2 shown for manually imported and certified cert
Ok, then this is only an issue in the VSD versions. (I confirmed with a quick test with Gpg4win-5.0.0-beta413)
Wed, Nov 26
Good catch. My guess is that get_uid_for_sender returns the last matching UID without checking for revocations. The matching was done on the mailbox part only. For reference:
Tue, Nov 25
I can't reproduce this on gpg4win-5.0.0-beta413 @ win11.
This seems to apply only for non vsd compliant algos. Importing and certifying a
- rsa/brainpool cert results in security level 4
- cv25519 cert results in security level 2
I rechecked: the revoked userid has to match the email address of the sender. Still there's another non revoked userid with the same email address:
Do you mean one of the user-ids has been revoked or the one matching the mail sender?
Mon, Nov 24
I wonder if we should better open a new ticket with all the relevant data when we get a report giving more information and set this one to invalid.
And meanwhile I have tested this a bit with VSD3.3.3 and in the case that the sender has a valid and *VS-compliant* key the automatic switching works.
Nov 21 2025
Looks good to me on gpg4win-5.0.0-beta413 @ win11
Looks good to me on gpg4win-5.0.0-beta413 @ win11
Nov 19 2025
Nov 18 2025
Nov 17 2025
Nov 14 2025
Nov 13 2025
Nov 12 2025
Nov 11 2025
Nov 6 2025
This here is resolved, for timegrids findings see other ticket, the issue is not related to the one from this ticket and no regression, as it turned out. And difficult to trigger.
Nov 5 2025
Test with beta32
Oct 29 2025
And when I switch of read-as-plain, both testmails in the inbox are displayed as expected but one of the ones from the sent-folder has an empty body:
This is a gif to show the UX. It is to complicated for words…
with 3.3.90.29-Beta:
Oct 24 2025
Right, it's the same with gpgol disabled. I set it to invalid.
But you are able to do this w/o gpgol being active?
Oct 23 2025
That's not surprising. The fix was made after GpgOL 2.6.7. And gpg4win-5.0.0-beta395 still seems to include GpgOL 2.6.6 only.
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Issue is still present in gpg4win-5.0.0-beta395 @ win11:
gpgol logs:
Maybe related to https://dev.gnupg.org/T7813
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Oct 22 2025
Oct 21 2025
Might there be a relation to T7842? But I would have thought that then all signed messages would be unaffected.
Oct 20 2025
that's probably at least partly another issue: https://dev.gnupg.org/T7843
Oct 17 2025
additionally, the body of the messages is (in most cases) not shown any more.
Oct 16 2025
With the beta-25 the body of the mail is not saved back to the server any more but the security level tags are. So the test mail still seems to be a signed and decrypted empty mail even if you deactivate gpgol.
We did decrypt the mail successfully and called put_oom_string to update the Body successfully, but for some reason for new mails the put calls succeed but the displayed Text is not updated i.e. no "OpenGPG Message Please wait..." or decrypted message.
When closing the mail window the mail is still open in the preview pane and we should get back the mail content (Body), but we don't get back what we set with the put call but what is displayed i.e nothing (empty string).
So we pass on the close call which does write back our put value. (Plaintext leak)
