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.

Additionally, we might want some sort of delayed or batched CRL-checking that doesn't block signature verification with another network interaction, but would protect the user against future problems.

Ah under Linux we ran into an assert which made finding the problem easy. The bug was introduced by the fix for T3602. Will be fixed in the next release. Apologies for the inconvenience.

Thanks for your report. I tried this several times. Could not reproduce it at first but I could get it to crash sometimes. Even without GpgEX just by double clicking the signature file.

Thanks for your additional suggestion. I pushed the change.

Confirming this bug in Gpg4win version 3.0.3 (previous version was OK).

I did a few more tests and here are some more observations:

For qt: adding /usr/pkg/qt5/bin to the path makes the build succeed. I think you should take a look at the build rules though, since it seems that it wants to execute the header file if "moc" is not found.

For BSD Make issue, please try:

Ah, yes. Will do. Thank you for reminder.

Thanks for the report.
Fixed in master.

For the latter, I think it requires path to moc, which may be like /usr/pkg/qt5. Please add it to your PATH. Then, retry from configure

Using BSD make on git head of gpgme, I see

Thank you. I think you can update the comment below the implementation now ("/* FIXME: Implement this when we have the specification for it. */) and the #error line.

Still open.

Fixed in rM37d62e9d0f68: core: Implement _gpgme_getenv for NetBSD..

Other problems are fixed. Please test. It works for me on NetBSD 7.0.2.

I just thought that going by your comment on Sat, Jan 27, 5:29 PM that you would use libdns, instead of resolv.conf directly. Maybe I understood that comment wrong.

dirmngr looks into /.etc/resolv.conf and does not know anything about systemd specific things (nor do I). Thus having a symlink seems to be an appropriate solution.

Note that it works as expected if I symlink /run/systemd/resolve/stub-resolv.conf to /etc/resolv.conf. Other programs appear to not require this change.

I can reproduce this issue with gpg 2.2.4, systemd-resolved and Arch Linux. Unlike the original reporter, I do not have 127.0.0.1 in my /etc/resolv.conf. I do however have it in /etc/hosts.

It turned out to be a bug in Enigmail. The "," in the key list s wrong.

Checked - it builds fine now. Thanks!

I push my change to master.
Please test.

1. Collect all data in OOM, then start a thread to do the encryption.
2. Do a proof of concept that this actually works and outlook lets us do it with our usual window message async handling.
3. Update my Keyresolver patches in Libkleo and build a "libkleo-tool" to do the key resolving.
4. Figure out Window Management / Create a Qt Overlay over the Mail window to block it from closing while encryption happens. This will resolve all bugs related to window mangement of the current key resolution.

Thanks for testing master.
No, it's not typo, in my opinion.
The line was added as if it's LOCAL_PEERUID, but there is no such a thing in XNU, but there is LOCAL_PEERUUID which is for UUID.

Regarding truncation, it seems draft of the RFC has some contradicting statements. In "5.2.2. {5.2.2} Version 3 Signature Packet Format" it says:

Your welcome, I can remake another unified patch if need be. I was starting to prepare things to be a stand alone fork. Did an initial .travis.yml file, and initial stuff for Coverity. Though never did get a build uploaded to Coverity. Not sure if you have ever run pinentry through Coverity or other GnuPG stuff, may be a good idea just to see if it catches anything.

I close this bug - if you can provide the log files please feel free to reopen.

Thanks for the long explanation. I think it should go into pinentry proper. I will have a closer look on it.