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

This can easily be solved by adding two more cases to handle_send_request_error(): for GPG_ERR_EADDRNOTAVAIL (that's IPv6 disabled via procfs) and GPG_ERR_EAFNOSUPPORT (that's missing kernel support). Normally I'd submit a patch but I don't care enough to jump through all the hoops just to get two-line change in.

Sorry, I don't understand. Can you describe your use case in more detail?

You have a token with one spare key which you want to use for encryption and certification. And being able to replace the encryption subkey eventually.

Originally dirmngr was designed to be a system service for the reason that CRLs are not user specific. However, the majority of systems today are used by a single user and thus we dropped that feature when integrating dirmngr into gnupg.

a key that is signed as its own subkey, in a construct where the key and subkey have the same fingerprint? what ever could be a valid use case for such a scenario?

Come on, it is in daily use for 15 years. MUA which can't handle MIME at all but PGP are still able to decrypt PGP/MIME. That is why ME specified PGP/MIME this way.

--use-tor does not avoid it because the CRL-DP can be made unique for each certificate. Depending on the verification model a CRL or OCSP lookup is necessary for correct evalution of a signature (shell model as used for qualified signature). This is why we in gpg honor-keyserver-url is not enabled by default; the keyserver URL take from the key is the OpenPGP counterpart of the CRL-DP.

I can't see why this should be out-of-spec. In fact I did this my self several times to create keys from other keys.

it is the decision of the user to use such a certificate.

uploaded the offending key for reference:

The implemented X.509 profiles require that the status of a certificate is to be checked. CRLs are also not looked up for each verification but only once during their lifetime. Some CA have unreasonable short lifetimes for their CRL but it is the decision of the user to use such a certificate.

I disabled your account but the I won't delete any comments of yours. They are considered to be in the public domain (see welcome page) and are parts of other bug reports. Thanks for those comments.