I think the reason for this is not Exchange Online but that I was using two explorer Windows and switched between Mails while the decryption on the slow exchange folder was still running. This triggered an invalidate_ui while the parsing was active and that then triggered a write / unload just like in T3523

When disabling CRL checks, you expose the user to drawbacks by outdated or revoked certificates. While I agree that improving implementations to not check the validation information too often or even build proxies is a good idea, I have a tendency to keep crl checking enabled for CMS crypto operations because it seems to be a lesser drawback.

Here's patches I used for testing. First is hack for disabing SHA1+RMD160 'old GPG LITERAL+SIG case' and second is 'iobuf_get to iobuf_read' optimization.

What's in daily use for 15 yrs? GPGME? I thought GPGME was new, but in any case it's broken in the cases mentioned in that thread.

My current idea is that if GpgOL detects that the provider supports a web key service and one of the following is true:

This is the log output for sending a GPG message to myself:

So I tried this on Outlook 2016 MSO (16.0.4639.1000) 32-Bit

I also think that when calling sign from the --edit-key interactive menu the experience should be a bit different. Instead of listing all the UIDs (even the revoked one) and then warning about the impossibility to sign some of them, it would be better to re-list only the UIDs that are going to be signed. In case --only-sign-text-ids is specified, the non-text UIDs should be stripped from this list too.

I think that it's the kernel problem in NetBSD, where signal to self cannot result EINTR for pselect.
Well, something like rG031e3fa7b9a6: scd: Wake up the select when new USB scan. can be applied, I suppose.
Let's see for configure.ac and HAVE_PSELECT_EINTR.

2.1.15 is a pretty old version. Please help us and try to replicate this with a 2.2 version and also give a log of the --delete-secret-and-public-key and --list-secret-key commands.

Great, thanks for the quick response!

Thanks for testing. I recall that I wanted to update the checking but a phonecall disturbed my hacking sequence; should have used DND.

No clue what their problem is, I have a few projects scanned by Coverity. Most are forks that I took over, but one is not really. Not sure why they took such issues here.

Okay. Thanks for the report. I once looked at Coverty but decided not to use it because of their rules which would not allow me to document and fix a possible security vulnerability without following their process. If there is a security problem I will fix it according to my schedule and not allow anyone to delay it.

Does this happen to you for all mails or just some? From the GpgOLXXX.dat I can't see anything wrong.
My expectation is that something goes wrong when updating the plain text into the message viewer. Again, could you please attach the GpgOL Debug output? That might help.

Steps 1. and 2. are now implemented in the async-enc branch of GpgOL. The keyresolver patches are updated for me and partially commited.

I have not seen this. But I suspect that it would be fixed if our encryption no longer causes Outlook to become "unresponsive". I'm already working on this for T3509 and have a development version which already does the encryption in a way that the pinentry / key resolution are just a modal dialog over outlook and no longer block the GUI of Outlook completely.

For scdaemon process(es), I created a ticket T3778: NetBSD: scdaemon should be killed when its parent (gpg-agent) is going to shutdown.

After fighting with Coverity over a fork of pinentry that has EFL. I setup to have Coverity scan. Which found some like 22 defects. Coverity unable to identify that I have any affiliation, after I spent/wasted hours getting a build to upload to Coverity to scan. Just to fight with some unhelpful person basically standing in the way of FOSS project, a wonderful Mel Llaguno. Decided for security reasons I be denied ability to use Coverity to scan pinentry for defects, even in the EFL interface I made and am the author of. Which also means I cannot fix other issues with pinentry or aide further in development....

FYI : when submitting a buffer composed of

• a leading 00 byte,
• the 255 bytes encrypted session key value

to HSM/PKCS11 for decyption, decrypt returns without any errors, and returned plain session key is the one expected.

Some enlightenments here because i may have not mention some info in the first place :

I'm confused. I've just now retested, and I get further with BSD make (there is another problem when importing the keys into the test keyring, where it the error is ignored with GNU make but the build fails with BSD make) but that is not what I want to focus on.

Our HSM is a certified FIPS 140-2, sec level3, hardware module, exposing a PKCS#11 v2.30 spec compliant API.

What kind of hardware token?

The patch is available in our downstream bugtracker as attachment to https://bugs.gentoo.org/646194