I downloaded GPGwin v3.1.3 beta 20 today. The automatic key fetching fails in my case because we have no WKS. Never heard of that before.

In the current gpg4win-3.1.3 beta 20 this is enabled again. It can be disabled in the options with "Disable non-blocking encrypt / sign"

I made it optional for now with default on. So that if it crashes it can be disabled. We need to see if the crash is a general problem or a special problem of that one tester.

We disabled the codepath that required this for now. Lets see how it works.

There were two things here:

Works for me now.

This was a very clear crash that is fixed now. Length was > 76 characters. This caused an improper realloc.

@Breach I was analyzing T4056 and wondered where I had seen the error from there before. And I found it in your log.

changing to testing is our marker for "done in code but not fully tested / released". It helps to keep an overview of the issues which are "done" for the next release.

Hi Andre,

This is implemented now and can be turned of in the new config dialog.

Good news! :)

Just as a note as you were the first to report this: I've finally found a solution. In the next version it will be possible to move around crypto mails. Hopefully your wife can then use GpgOL :-)

The new idea worked! It is now possible to move mails even while their decrypted content is shown!

A new Idea which I'll have to test:
Register an event handler for each folder in which a decrypted item is read. "Mailitem->parent" In this event handler listen to the beforeitemmove event. In that event then close the mail / discard the decrypted contents.

T3961 Needs this
T3999 also

It's currently enabled again with 27e7dfb1280f314286348a661e057eef5c8ab440 I had another intensive look at the logs from the user where it is crashing but I still don't see a problem.

Am 21.06.2018 um 10:31 schrieb aheinecke (Andre Heinecke):

aheinecke added a comment.

Beware: Beta-7 was bad timing, yesterday I was in the middle of
implementing T3999 https://dev.gnupg.org/T3999 and broke the
internal keycache. If you use "Empfängerschlüssel automatisch
auflösen" please switch back to a different GpgOL Version. I might
upload a new Beta soon but for now I've removed Beta-7. Automatic
resolution will not work with that version and can lead to crashes.

*TASK DETAIL*
https://dev.gnupg.org/T4037

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

*To: *aheinecke

*Cc: *aheinecke, JJworx, Rafixmod, ccharabaruk, Mak, 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.

Beware: Beta-7 was bad timing, yesterday I was in the middle of implementing T3999 and broke the internal keycache. If you use "Empfängerschlüssel automatisch auflösen" please switch back to a different GpgOL Version. I might upload a new Beta soon but for now I've removed Beta-7. Automatic resolution will not work with that version and can lead to crashes.

Yes, that did the trick for me!

Nice, then my commit should fix the issue here.

Yes, definitely the real reason is in the inline editor.

I can't confirm the regression yet. For me (albeit with Outlook 2016) preselecting sign / encrypt based on the options works for reply and forward. But only as long as the Mail is opened in a dedicated window.

Thank you for your fast fix!
2.2.1-beta2 works as expected!

As expected it was a very clear bug. We assign a NULL pointer to a string and then use that string.

Thank you for the report and the logs! A minor note: For future reports please leave the priority on "Needs Triage" we use this as a marker for issues no developer has looked at previously.

This is still true even after the latest changes to GpgOL not to require Kleopatra or GPA through the UIServer protocol. The details dialog / search still uses Kleopatra or GPA as a fallback.

I'm closing this as a duplicate of T3459

Two more reports in the Gpg4win forums. Still can't reproduce it. I've asked for debug output.

I'm closing this as duplicate of T3459

Has long been in testing. I think it is improved now and CRL's also work.

The changes were released with Gpg4win-3.1.2.

Fix is released in Gpg4win-3.1.2

Fix is released in Gpg4win-3.1.2

The problem is complicated because we would have to parse each multipart/mixed mail before we can know that the mime structure looks that way.

Support was removed.

This was released with Gpg4win-3.1.1

Fixed with https://commits.kde.org/libkleo/79f0cb79817e44b4eab864c573740c1501e796bd

Thanks for the writeup. Maybe this could be the base for a gnupg.org/blog article.

Here is what we have now. We decided explictly not to offer a "yes I want to do something less secure" button as we think that using Unsigned S/MIME Mails is avoidable. Also we want to be more secure by default then Outlook. From a User Experience standpoint a "Yes more convenient but less secure" button basically educates users to always select that button.

I've noticed during testing that GpgOL would not send valid PGP/Inline signed only messages and also failed to verify such messages itself when special characters were in the mix.

Oops. The commits added here belong to T3975

Thanks for your report, but as JJworx already said this is sadly one of the known issues to which we don't yet have a good idea how to fix it. In T3459 there is an animation what is meant by "unselecting" the mails.

Yes, this is actually pretty high on the wishlist but AFAIK there was not yet a task for this.

There won't be anything without MDC in 2.2.8 anymore.

The best way to send signed or encrypted mail is by using PGP/MIME which is the default.

Thank you for your answer.

I've tried to prevent the download of external references selectively for S/MIME Mails. There is PR_BLOCK_STATUS but I was unable to stop the question for the user if she want's to download the external references anyway. :-/

Thanks for your report.

Thanks for the report.

In another report, it turned out to be, that with a 64 bit outlook and GnuPG not installed in the standard location it came to this error. ( T3988 )

We've analyzed another report of this and the problem turned out to be that with a 64 bit outlook and GnuPG not installed in the standard location it came to this error. ( T3988 )

Yes. For S/MIME we don't have the comfort to change the standards. I also would like to have a quick solution. After much deliberation with Bernhard we think that it is a good compromise from usability vs. security that we further reduce the usability for S/MIME in that we only allow (any) signed content to be displayed as a file or HTML. This is not extending the standard, not changing GPGSM but a design decision in GpgOL.
We don't have full control over our Mail client so we can't prevent the load of external references like KMail does. This suggestion is a compromise and a pragmatic solution.