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

Unfortunately, the configuration dialog does not work at all for me. It says "The shared library was not found.", but it fails to say which library was not found.

The compliance with VS is stated in the tooltip. Is that sufficient or shall we make it more prominent with a background color?

There is a tooltip saying "May be used for VS-compliant communication." for compliant keys, is that enough highlighting? Or shall we give those keys a light green background color or something?

So I started with this one because it was the easiest. To reduce message fatigue, I only display compliance information if gnupg is in co-de compliance mode.

Is this about the gui not offering e.g. the wrong algorithm or key sizes in the first place? If so, then we have to either hard-code it in kleopatra, or communicate it from gnupg. I guess at this point, we'll have to hard-code it :/

Please reopen if this is still an issue with the latest version of gpg4win.

Please reopen if it can be reproduced with a recent version of gpg4win.

https://files.gpg4win.org/Beta/current/

Unlikely

GpgOL has even been revamped 2 times since then.

Is this still an issue with the latest version?

Is this still an issue?

I don't think we can do anything about slow startup times due to anti-virus software, sorry.