gpgOL cannot decrypt E-mails. No Data.

This is a weird one to me.

Windows 10, latest update.
Outlook for Office365.

Basically GpgOL will not open my encrypted files.
that said, when I click the e-mail. I can see the descrypted text for just a second before it disappears into “cannot load data”.
This happened when I updated to 3.1.14

Tried to revert back to previous version, as well as 3.1.12, without results.

Decided to do a proper cleaning. Uninstalled Gpg4win.
Deleted the following:
C:\Users%user%\AppData\Roaming\kleopatra
C:\Program Files (x86)\Gpg4win
C:\Program Files (x86)\GnuPG
Reg computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Outlook\AddinsData\GNU.GpgOL
Reg Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Addins\GNU.GpgOL

Rebooted, installed gpg4win and restored file from backup.
Still the same error persists.

When activating logging, I can see the descrypted message in the full log. So it appears that there is data being decrypted. But somehow GpgOL don’t manage to show this in Outlook.

Any idea how to resolve this issue?

Same to me, pls refer to
https://forum.gnupg.org/t/gpg4win-3-1-14-bug-with-gpgol-2-4-8/3625
also…
Best regards!

Additional:
Decrypted message flickers very short, afterwards no-data message is shown.

Ah, so maybe here the decryption succeeds then it will try to verify a signature and that fails with no data. Quite possible if the mail structure is somehow unusual or some other interference blocks us from obtaining the signature.

Could you attach a log from a decryption attempt with a test mail? Or send it to me at aheinecke@gnupg.org if you don’t want to attach it publicly.

I’m not sure if this is the same problem as the other “no data” problem because afaik the other one was addins interfering.

Thinking about this, we should always show decrypted content even if verification fails in an unusual manner, so I’ve opened https://dev.gnupg.org/T5164 to stare down the code at least and check that if we can somehow decrypt but fail to verify that it will always show the content. I think we already do that.

An alternative explanation could be though that it tries to decrypt unencrypted content. That would be similar to the permanently decrypt issue we had some time ago. In that case we might also want to store a previous body / attachments and restore them on failure. I don’t think the code does that yet.

So there is something I can do here without more information.

I have added some more error handling code for the NO DATA case. In that case GpgOL will now print which data it tried to interpret as an encrypted message and why. This could show plaintext when it tries to decrypt unencrypted data and might otherwise indicate what is wrong with the messsage structure.

Could you please try:
https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

With: https://files.gpg4win.org/Beta/gpgol/2.5.0-beta11/

gpgol-no-data-handling.png

Two mails have been send to Andre, including screenshots and logs for:

  • GpgOL-2.4.8
  • GpgOL-2.5beta11

Best regards, Chris

Chris sent me debug output that helped me to finally understand this enough to reproduce it.

Fix is incoming.

Hi Andre,
thanks for looking into this.

A small question / remark, you wrote:

we should always show decrypted content even if verification fails in an unusual manner,

Is this safe in all conditions given the crypto gadget attacks?
(If something else is put into the crypto stream and then appears in the reply.)
I don’t have the overview about all cases right now, but trying to point out something
to watch out for early.

Best Regards,
Benrhard

Yes this is safe against gadget attacks, our protective measures like blocking html for that and not reply / foward still work in all cases. I thought about this a bit if it can be harmful regarding HTML in the message but its not.

Workaround for the issue: Disable “auto-key-retrieve” in the gpg.conf until a new Gpg4win release is out.

Or use: https://files.gpg4win.org/Beta/gpgol/2.5.0-beta12/

The reason for this was the “Preview” “Please wait while the message is verified…” added in GpgOL 2.4.6.
That only worked for PGP Messages when the message was encrypted and signed in a single step and not the more usual PGP/MIME way of encrypting a signed MIME Message. I’m not sure why I not caught this when testing this feature but I mostly tested S/MIME and for S/MIME I already handled this properly.

So with auto-key-retrieve GpgOL wants to verify the mail twice, once offline to be quick, and once online to maybe download a new signing key from a keyserver. And for encrypted messages it wrongly tried to decrypt the already decrypted content again on the second pass.

Hello,
working with:

  • GpgOL-2.4.8 and “auto-key-retrieve” deactivated in gpg.conf.
  • GpgOL-2.5beta12, “auto-key-retrieve” can be still enabled.

Really nice, thanks and regards!!

I replaced the Beta files here: C:\Program Files (x86)\Gpg4win\bin
(x64 file in the bin_64).
But I am still having same issue. Plugin in Outlook still tells me that it cannot check signature.

What am I doing wrong here?

Hi Kim,

originally you reported that it could not be decrypted and shown.

A signature checking is a different thing. :slight_smile:

Maybe the signature has other problems?

Best,
Bernhard

Quite possibly so, yes. :slight_smile:

To add to my original issue.
I see the decrypted text “flicker”. Basically allowing me to see the content for a split second, before the mail going blank again.
I can decrypt the mail in Kleopatra notepad. But where it also state that it is not signed.
I send mail to myself, to ensure that it is encrypted and signed with known working certificate.
Also attached log in hopes that someone can help.

Also, uninstalled both Office/outlook and gpg4win several times, in hopes of finding a way to decrypt messages again.

Let me know what else information could be helpful, and I’ll do my best to retrieve this.

gpgol.txt (98.9 KB)

Hi Kim,

Thanks for the log, this actually shows me that there is another case that is now broken. :sunglasses:

Still, the workaround to remove “auto-key-retrieve” from %APPDATA%\gnupg\gpg.conf should also work for you.

But I’ll let you know when I have a new version that should also address your issue here. I think its a pretty simple logic error on my side.

Thanks for helping ironing out this feature. It’s all related to the fact that GpgOL now tries to show a verification result before it did any online operation to possibly obtain updated key material or S/MIME CRL’s.

Uhm, wrong.

Sorry, no your log says

11:49:27/13244/keycache.cpp:protocolIsOnline:Detected no online options.

So this is not true. Please disregard my last comment here. I was too early and double checked when I could not reproduce the issue. I misunderstood your log. I have no clear Idea what is wrong here yet.

Please do let me know if you’ll need additional logs or something else, and I’ll do my best to test and try of course.

All the best.