@dcialdella I've checked the Ubuntu Patches, they don't include the patch that caused the problem for GpgOL in this issue. Please report your problem either to Ubuntu or open a new issue, ideally with some instructions how to reproduce your problem.

At the very least the dialog should not be easily closable if the CSR was not exported to a file. This makes it too easy to accidentally loose the CSR.

I've just checked the current build to the previous one (even when I get rid of the build directories, I keep a copy of the config.log since you never know when it might come in handy).

FYI: this most recent update broke builds on OS X 10.9 for Qt, but everything else is fine.

No longer happens when the good old ldapwrapper is used.

By standard I mean "behaves" somewhat like coreutils. Filename encoding,.. meh I see that this could be a problem.

gpg 2.2.4-1ubunt amd64 GNU Privacy Guard -- minimalist p

It's possible that was one of the upstream patches they decided to include.

@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"

Hi Andre,

Thanks for the tip, moving unopened secure email to a folder is the solution, I guess I just had to ask.

Beta? the last issue I report I was told to test on the beta which worked and forgot upgrade afterward.

ALL GOOD! Merci!

Jacques

From: aheinecke (Andre Heinecke) <noreply@dev.gnupg.org>
Sent: April 27, 2018 12:43 AM
To: Jacques Latour <Jacques.Latour@cira.ca>
Subject: [Task] [Closed] T3943: gpgOL

aheinecke closed this task as "Invalid".
aheinecke added a comment.

yes sorry, but due to a design limitation it's impossible to move mails while the decrypted / verified content is visible. Our task for this is T3459https://dev.gnupg.org/T3459 (so I'm closing here as invalid even though the problem is valid.)

As workaround you have to move mails while they are not shown. E.g. if you move them without selecting them, or unselect a mail by shift clicking it. Here is an example what I mean by that:
https://files.intevation.de/users/aheinecke/gpgol_moving.gif

Btw. Is there a reason why you are using a beta and not 3.1.0 ?

TASK DETAIL
https://dev.gnupg.org/T3943

EMAIL PREFERENCES
https://dev.gnupg.org/settings/panel/emailpreferences/

To: aheinecke

Cc: aheinecke, latour_jacques, gp_ast

This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.

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

Oops. I also opened T3939 about this.

yes sorry, but due to a design limitation it's impossible to move mails while the decrypted / verified content is visible. Our task for this is T3459 (so I'm closing here as invalid even though the problem is valid.)

Still happens. There are also "BER" errors that seem random.

Alright, I will create a ticket with Exquilla to see with them if this could be fixed on their side.

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.

See also T2448

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.

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.

Looks ok now in my tests. I still want to test against more CA's with more CLRs (e.g. COMODO and CACert)

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.

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.

Mh, we can probably drop the GPGME part of this. In the longer term I'm hoping for the automatic refresh in dirmngr. So that refresh-keys would not be needed.

Are you asking for a way to --refresh-keys via GPGME? IF so shall that be a syncronous thing or just a trigger. Note that we the last update time is already part of gpgme_key_t and can thus be used to check whether a trigger worked.
Anyway this will be a larger change and may need gpg support.

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.

A reason we did not touch it in the past is that Ideally we don't want users to have to mess with refresh keys but would rather have this done automatically in the background by dirmngr.

I wonder if CACert intentionally sabotages X509 / CMS.

3.1.0 is released and this issue is to our knowledge fixed.