Tue, May 26
Mon, May 25
Tue, May 19
This was implemented0d2db8b81ab24e2ab02d7ba6832cabd07b72f852 in Gpg4win-3.1.11 but does not work reliably.
Closing with Info Needed.
I'm moving this from testing to open again. Especially the deletion is an issue. I had a report that even for a sent mail Outlook.com also stores an unencrypted variant in the "Trash Bin".
This was released in December 2019
Mon, May 18
- Looked into performance issues of GpgOL, turned out that other Addins were causing high amounts of decryption
- Implemented "Preview" in GpgOL to show contents of a mail while verification (auto-key-retrieve, CRL checks etc.) happens.
- This is esp. helpful for multipart/signed because it can show contents immediately.
- Fixed printing in GpgOL when the selection of the printer changes.
- Triaged some more GpgOL issues. Tried out "MailArchiver" plugin.
Fri, May 15
Thanks for the logs. I can see the crashes, but I can't make heads or tails of them. We crash in completely valid code. I really don't want to play the blame game here but to me this would be explainable if there is an issue with refcounting in the GFI plugin that would release the IMessage or ISecureMessage MAPI Object from the ItemLoad event once to many. In that case the object we work with might be deleted at random times and that would explain it.
Thought of a way to at least mitigate it. When a mail is closed we know it's not printing.
After looking at this for 4h I could not see a way to detect it better when a print job is done. So we now treat every ItemLoad of a mail after we have seen the BeforePrint event as a print.
Outlook is a bit nasty here:
Thu, May 14
Tue, May 12
could you please go into the GpgOL setting and under "Debug" turn on logging on the highest level (+code trace) and then reproduce the crash and add the log here?
Including Data should not be needed so you can keep that checkbox unchecked to avoid having mail data in the logs.
This might help us to see where and why the crash occurs.
Fri, May 8
I'm not sure what to do here. The problem is that all users in clients without PGP/MIME Support will see the attachment names. That is why we use the names as they are.
There was a similar Problem in the past reported on our mailing list:
Thank you for your work, appreciated. Sorry I was a bit under the weather in April and could not get back to you earlier.
erstmal vielen dank für das Feedback. Ich habe momentan als Aufgabe ein neues Benutzerhandbuch auf Basis des Kompendiums zu erstellen und werde da die Hinweise auch mit Aufnehmen. Technisch ist sowohl der Inhalt als auch die Art wie das Handbuch erzeugt wird nicht mehr aktuell, wir brauchen da dringend etwas neues das wir auch online stellen können.
Sollte noch in diesem Jahr passieren.
Right. GpgEX is in serious need of polishing. I'm not sure if I'm in favor of processing all files recursively. But then the decrypt option should not even be shown.
From the commit message:
Thanks, I can reproduce the problem. I'll look into it, printing mails is important for some ;-)
This is not the first report I have gotten about mailstore problems. My suspicion here is that the mail is opened read only or somehow got the wrong properties from mailstore.
Thanks for the patch, applied!
You are correct the NEWS file states that this was added in 1.9.0
I can reproduce this.
I've just tried the test suite of GnuPG 1.4.23 on debian buster and all tests pass.
I keep it open as testing so that we keep it in mind for a release.
There was a patch for this by david faure which added an
#undef ttytype after including curses.h