Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".
Yes, I can confirm that log entry.
Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".
Yes, I can confirm that log entry.
Yes I see the problem and have a fix for it. I'm just trying to make it nice now :-)
Yes, I also can't decrypt the files there. As Outlook warns about
restricting access to attachments and active contents, the reason is
clear. The mail must be moved elsewhere.
I can reproduce that it won't be moved.
This issue is pretty old and I think anything here was fixed in recent releases. So let's close this to avoid artifacts in the tracker.
A wait, we have T4203 for the continuing problems. So let's close this.
This was likely one form of T4111
3.1.4 was released.
This had also something to do with the missing keycache that will be released in 3.1.5 so that sometimes S/MIME keys were not cached internally and so would not be used.
There is still at least one report claiming that this still happens for large attachments. I could not reproduce it.
This was fixed with the Gpg4win-3.1.4 release. Apologies that I forgot to mention a pre release version / installer in this issue.
I've tried to reproduce it but failed. Even If I open the message in a new window or a new explorer the message is correctly caught.
Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".
Looking at the GPGME code the ERROR stati don't matter because they are only used to return a better error code in case an operation failed. The specific ones are not even recognized.
No info received.
No more complaints thus time to close.
Fixed in master and 2.2.
I consider this bug to be solved.
MacPorts doesn't currently ship the bindings at all, but I'll see what they need to make that a reality too.
While this is now ideal for Debian, it may cause conflicts with other downstream vendors with slightly different needs to build their packages. In particular the FreeBSD ports and/or pkg system.
Thanks for the report.
Yes. Thanks! I'm at over 2500 S/MIME verify operations without a crash now!
Yes! Thank you very much. My test runs and my Outlook has verified 2500 S/MIME Mails without a crash.
The T4237 fix should also fix this one.
To avoid the drawback, we can put the logic of locating possible libdir in gpg-error.m4, instead of putting in the script.