Hi Andre,
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 17 2023
Sep 14 2023
Thanks Andre for your response..
I am pretty sure that we can fix that issue and have a beta for you maybe even today or tomorrow. But afterwards we should talk about your company actually using a product with professional support (which you are getting right now from me) like GnuPG Desktop. Gpg4win is basically only "goodwill" support.
Sep 13 2023
I tested once more with another person, issue confirmed, he can read my encrypted mail (as you did), however, I can NOT read his emails (with the same error: you cannot be sure who encrypted this message as it is not signed)
Sep 12 2023
Yes, I can decrypt my sent mails, in my Sent folder
To say this differently, the problem fixed recently which Relaxed detection of encrypted mails might still fix your problem. But the "corruption" of the mail which makes it harder to detect as a crypto mail for GpgOL does not happen when you send a mail, it appears to happen when you receive a mail.
Received, but it is not the same problem at least on your side. Your mail looks perfect. It would have been handled by any version of GpgOL on my side. So I think it is the receiving side meaning your incoming crypto mails are modfied by some middleware in a way that GpgOL does not detect them as crypto mails anymore. But before we debug more here with logs for you, let me finish up some other work on GpgOL and I can probably give you and some others in the tracker here a beta this week where we can then confirm if its already fixed. I'm currently actively working on GpgOL.
I sent the test encrypted email
Thanks once more... and appreciate your swift response.
Yes the resolution in that issue is "I have fixed this, you need to wait for the next update." The comments above explain the problem, the mail is modified in transit, if you change something there then you can maybe workaround in the meantime. The exact comment I linked gave the instructions on how to assist with analyizing this issue. If you would follow them I could also tell you for sure weather or not this is your problem. https://dev.gnupg.org/T6686#174856
Thank you for your reply.
Ok. Let me unpack this for you. I think your problem is that now since you switched to your new domain the mails in Outlook are no longer directly decrypted, then you open the attachment and get this message.
I am closing this, for now as this issue lacks actionable details, we would need an example mail or debug data. So my intent is just to close it and reopen if the issue still occurs with Gpg4win-4.2.1
Noticed this issue while searching for a different one.
I think this could be fixed with T6686 if it has not already been fixed by a previous change that relaxed the detection of the encrypted message part better.
Sep 11 2023
For another user this change caused endless syncs. Since I do not yet see a way to fix this without risking again that the plaintext leaks to the server under some circumstances, because the problem is that I still do not know how to reproduce these circumstances, my plan is to at least add an option in the debug tab of Kleopatra to disable this "save back" feature.
Sep 8 2023
Sep 7 2023
Sep 6 2023
Another customer case with "always show security-dialog" on (-> external resolver):
Sep 4 2023
Sep 1 2023
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.
Aug 31 2023
Aug 30 2023
Aug 28 2023
Changed the task description to easier find it
Aug 25 2023
Aug 23 2023
Aug 22 2023
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?
Aug 16 2023
Aug 11 2023
Aug 9 2023
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.
Aug 7 2023
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 .
Aug 1 2023
This fix was pretty minimal and I could test:
Jul 31 2023
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.
Jul 27 2023
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.
Jul 25 2023
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.
Jul 24 2023
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.
Jul 20 2023
Jul 19 2023
Fix pushed to the 23/07 branch and master.
Jul 18 2023
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.
Jul 3 2023
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
Jun 30 2023
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.
Jun 29 2023
Jun 28 2023
This will not translate into the new addon and is too large a change for the current one.
Jun 26 2023
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.
Jun 20 2023
Jun 19 2023
Jun 5 2023
Jun 1 2023
Works good enough for me
May 15 2023
Fixed with: 8e258f77114ce0474a2bb6aa1314385e2fb68e15
With the recent commit the old workaround works reliably again.
Apr 27 2023
Apr 24 2023
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.
Apr 19 2023
works, a key with a revoked uid is accepted as VS-NfD compliant, VS-Desktop-3.1.27.0-beta44