It's possible that was one of the upstream patches they decided to include.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 30 2018
@dcialdella Do you have a "non standard" GnuPG / GPGME installed? What are the versions?
I have the same issue with Xubuntu 18.04 lts, and GNUPG.
./start_linux_64bit
[Error] Source: GPGME String: "Invalid crypto engine"
[Error] Source: GPGME String: "Invalid crypto engine"
[Error] Source: GPGME String: "Invalid crypto engine"
Apr 27 2018
Ok so it was impossible to detect when a mail is printed and block the printing until the decryption was completed.
This was fixed with 7eed3c4c5e9f84bed0e412213cf404a18cd54358
Apr 26 2018
Apr 25 2018
Alright, I will create a ticket with Exquilla to see with them if this could be fixed on their side.
Thanks for your report!
Apr 24 2018
Very strange behavior caused this. Outlook seems to detach from an object model call, handle a window message, and then return the object model call.
Apr 23 2018
Apr 21 2018
Also confirming the workaround. Not sure whether it would have done me any justice to counter-sign the key after accepting it locally, since I only verified it against their web page. The web page is hard to find with a Google search, since Google does not turn the unspaced hexadecimal fingerprint into something that matches the space-every-four-digits format used on their PGP/GPG instruction page. Searching for "Facebook PGP key" works, though.
Apr 20 2018
This task and Forum reports about CRL errors caused me to investigate a bit and we found a Bug with CRL's on Windows. T3923 which might be the root cause.
Was Okish in my last tests. But I did not fix anything compared to 3.1.0
The commit mentioned fixes the problem.
I can confirm the workaround. After importing the key from Facebook everything works as expected!
Thank you very much!
Thank you very much. It helped. I can reproduce the problem now.
Same here with Mails from Facebook, here's the log
"Invalid crypto engine" Means that there is some internal error in the signature verification / decryption.
I got an Idea how to improve the situation here. But its very complex and might break Outlook even for unencrypted mails. So it's very invasive.
Apr 19 2018
Ok I tested with Exquilla. I configured an Exchange account once through Thunderbirds built-in account (IMAP) and once with Exquilla
Thanks for the report.
I clarified the title a bit to include exchange / exquila.
Let's use the new issue as the problem is described completely there and it makes it more clear.
Apr 18 2018
I already created a new issue for this in the new version of gpg4win (v3.1.0) with GpgOL v2.1.0. This is the issue: T3917.
Apr 16 2018
Apr 15 2018
You can close the report.
I'm working with a restricted user and I installed gpg4win-3.1.0 with admin rights, probably didn't work so well.
Apr 13 2018
( Apart from the part that was moved out to T3895 )
3.1.0 is released and this issue is to our knowledge fixed.
3.1.0 is released and this issue is to our knowledge fixed.
3.1.0 is released and this issue is to our knowledge fixed.
3.1.0 is released and this issue is to our knowledge fixed.
3.1.0 is released and this issue is to our knowledge fixed.
3.1.0 is released and this issue is to our knowledge fixed.
3.1.0 is released and this issue is to our knowledge fixed.
I think you are running in the infamous T3459 "As long as the decrypted content of a crypto mail is loaded a mail can't be moved" You have to unselect the mail and then move it without opening it. E.g. by right clicking it. I know this is horrible and it's a major problem but I don't see how we can fix it in our architecture. As we replace the mail content with the decrypted stuff we have to prevent "Write" Events by Outlook. For Move if you block a write event, the move fails. But we don't have any idea in our addon when a write comes from a move. I spent a lot of time on this and have not yet found a good solution. But I think the workaround is kinda ok.
The Bug is here that the Error is not shown properly. In the log:
Apr 12 2018
With the changes in 3.1.0 I think this is acceptable enough that we can move further improvements to this to a lower priority.
We only support PGP/Inline (no-mime), warn if an attachment is also added. A user could send attachments encrypted on a file basis.
I've opened T3895 for a permanent decryption / permanent removal of attachments. Maybe something for 3.2.0 ;-)
When an attachment of a crypto mail is removed it now leads to a warning.
In my tests it does work nicely now. We detect the "Send Again" state and correctly handle it. Sign / Encrypt is preselected depending on the state of the original mail. Even works with attachments.
Never seen the crash again.
Apr 11 2018
Accidentally mixed up the ticket number. The correct commits for this ticket are:
Oops. I confused the ticket numbers rO34f6bb73882e: Implement send again for crypto mails. Would be the correct commit for this ticket.
Right, outlook.com is often problematic, although it might be a generic Exchange 2016 problem. Outlook.com and Exchange 2016 behave much the same.
I'm not sure about that (Bug in Evolution), because I see ist only in E-Mails send by Evolution via Mircosoft (outlook.com) and not if Mails werden send by Evolution via Google (gmail.com).
Apr 10 2018
I've got an example mail. The problem is that the mail itself is "Content-Type: multipart/mixed; boundary="_003_DB4PR08MB01092D175DE8C1861B5D0BC197BF0DB4PR08MB0109eurp_"
"
I'll go for a warning / error for now and see if I can fix the renumbering.
Apr 9 2018
In fact, renumbering of attachments happens also by just viewing them repeatedly. This likely causes multiple copies somewhere, reducing disk space.
Thanks for the report and the spelling fixes :-)
Thanks for the report.
Apr 6 2018
Apr 5 2018
This problem should be gone with Gpg4win-3.1.0-beta48. While I could not reproduce it I've tried to fix it and changed the hard error to a debug log in case something is unexpected here. I believe that this is safe.
I tried to reproduce this again, using S/MIME Mails, installing gpg4win 2.x etc. It did not crash for me :-/
Apr 4 2018
I doubt that I will be able to fix this. The problem is that for Outlook we build the signed mail structure, which is a multipart MIME message. If you receive such a mail with a non crypto client you see the plain text and a pgp-signature attachment. That is why Outlook shows it as "attachment".
Normal prio as I don't think that this is a regression.
Thanks for trying out the beta. I was about to open an issue about this as someone in the forum reported the same thing. https://wald.intevation.org/forum/message.php?msg_id=5759
Mar 29 2018
Mar 28 2018
Mr. Heinecke, to make sure, please note that despite the thread title these crashes happened with 3.1.0. beta 38. It would be sad if you do all of the tests and checks with 3.0.3
Apologies for not replying to your mail directly. I've marked it in my INBOX to do the test with 3.0.3 first but have not gotten around to it.
Funny thing, it worked for some time, now it's reproducably crashing again. This might be the better log file.
So, this is tested with 3.1.0 beta 38, reproducable crash
I answered by mail in this fashion:
Mar 27 2018
Mar 26 2018
rO4c5eed308829 fixes this.