There are more Logfiles:

Are those mails sent by GpgOL with Outlook or recieved? Can you explain your complete Workflow and state what software was used in it?

Can you relate to the issue described in the GPG4win Forums?

You could try to use NO-MIME (or PGP/INLINE) instead of the OpenPGP/MIME standard. You can change the way of packaging your encrypted content in the GpgOL Addin Options.

Confirmed. Same behaviour and environment as described by HB1000 but with Windows 8.1 x64.
Outlook displays a message inside the mail "decrypting message..." (something like that) and then the message window is blanc as if there is no content.

Do you have any idea about this issue?
Exactly same behaviour here.
Windows 7 Enterprise 64-Bit, Outlook 2010 (Version 14.0.7188.5002, 32-Bit), GpgOL 2.0.1
Tell me if you need any diagnostic logs, ...

I'm also facing the same issue here.

Oh, God, someone please solve this problem. It is so annoying. Tried everything I could, installed and uninstalled the softwares and accomplished nothing.

i'm facing the same problem. Would love to see this problem solved

I'm also facing the same issue here.

I’m facing this issue too..

That seems to be a conflict between the two extensions. We need to look deeper into that so learn why it could go wrong and whether there is a way to work around the conflicts.

If someone could help me on how to debug on outlook, I could produce more information about this bug.

See T3441 for one additional screenshot with error codes.

The log file shows that gpgex (or explorer) crashes.

The output from gpgsm -K in the last quote is perfectly okay. -K works by iterating over all public keys and checking for each public key whether the private key part is also available. If the private key is not available gpg-agent returns an error.

This doesn't seem just to affect E-Mails but also File-Encryption.

I'm trying to find all relevant information first, then we can discuss who should work on this.

So, who is going to work on this?

I recieved the Log File of a user which may helps analyzing this problem further

I think it was a version problem.
I have now installed gpgOL (2.0.1) and gpg4win version 3
It's working.
Just that emails do not directly access "decrypt", but those that are sent from MAC arrive as an attachment, with ASC termination. I need to change the extension to PGP, decrypt, and generate a file without extension. Then I need to change the extension to EML and then I'll be fine.
Can you fix it?

I assume you installed gpg4win. Which version did you install? 3.0 is the latest.

@aheinecke is completely right. I just copied from Outlook's "show source".

We now explicitly delete the body instead of relying on the fact that the Outlook MAPI to MIME conversion deletes the body. Somehow this worked in the past but no longer does. I could not bisect it as 1.4.0 showed the same problem but old test mails from July 2016 did not show the problem. Newer ones from August 2016 already showed it in the sent mails folder.

I think this is a duplicate of T2416 please let me know if you still see the crash with the current beta / release candidate of gpg4win-3.0

This is fixed now with ef038f2d1db15ef14c238137c1c42a99bbe25f42 initially we only took the first attachment. Now we check for the position of the created MOSS attachment. This explains why a second try worked because the MOSS was already created.

This is what you get if you "show source" in Outlook so it's only the headers.

Is that really the entire mail? I can see only the header of the mail but not the body. How did you copy the raw mail?

Talked with Jochen and tested this. Jochen's test forwarded the mail so he ran into T2854

I can't reproduce this issue. I've imported the attached mail with KMail and synced the folder to outlook.
GpgOL did decrypt the mail. It did not set the category correctly (These were two other bugs which I've fixed now) and displayed the wrong status information but decryption happened.

Outlook 2003 is no longer maintained.

I think its done and released with beta-270

There is highlighting now but we don't have the fancy new keyresolver.

No. But as of 3.0 GpgOL for Outlook 2003 and 2007 is no longer maintained and the support for this will be removed in some future version. This bug only affects new installations of GpgOL on the unmaintained (by Microsoft) Outlook 2003 and Outlook 2007 Versions. So -> Wontfix.

Should be resolved. Reopen if it is still an issue.

@aheinecke did you change the default?

Ok this looks nice already. My plan is the following:

Andre merged this already.

Merged.

Merged.

Merged.

3DES is indeed an allowed cipher, so that is not a concern. Changing the cipher to something that is not allowed does not work.

In T3236#99866, @aheinecke wrote:

In T3236#99865, @justus wrote:

The whole "GnuPG System" section?

No, only the options that are marked as "advanced" by gpgconf.

Actually, Andre has some uncommitted changes that do implement the wanted behavior. AIUI those mainly needs a little fix to so that it wont break with old GPGME versions. Once merged, I will amend it further if necessary.

"aheinecke (Andre Heinecke)" <noreply@dev.gnupg.org> writes:

In T3236#99865, @justus wrote:

The whole "GnuPG System" section?

"aheinecke (Andre Heinecke)" <noreply@dev.gnupg.org> writes:

I'm not sure if this is really a thing, maybe it would be enough to just disable showing the advanced options in Kleopatra again. I only recently enabled them.

Yes, it is probably correct: the concept mockup was done a lot earlier. Whatever we have in master is most likely the current status.

The mockup in the design document shows a completely redesigned key selection dialog. I did not see anything like that currently in Kleopatra. Is that right or did I miss the new dialog somehow?

Can you please provide more information about the versions you are using?

PGP/MIME is supported since Gpg4win 2.3.

Some details of these tasks are outline in the internal concept, including mockups.

Hi,
on which platform? (You can probably compare it to a working version and see which libraries is uses there.)

This actually uses the same infrastructure.

I implemented a key filter that is used to modify the key appearances. For now I use a light green for compliant keys, and a light red for non-compliant keys. One could as well introduce an icon with the same method (i.e. it is easy to change), but aiui the icons are already used to display trust levels. Patch is pending.

I now display the compliance status d for the decryption process. Patch is pending.

Disregard my comment above. I now display the compliance status for every signature and for the decryption process.

I patched Kleopatra only to offer compliant options in the generation dialog. Patch is pending.

Relevant upstream patch submissions:

We need a more prominent visualisation for compliant keys in key selection dialog of Kleopatra. E.g. as icon.