As written in T2438:

I think that this is same issue of T2438: dirmngr fails repeatedly with "invalid argument", without kicking the host from its list.
Merging.

For the problem in the last comment, it was fixed in T2928: stop fetching PTR records entirely.
For the original issue, it looks that EINVAL is returned by the system call of connect(2).
That's quite strange, but, it was possible for IPv6.

could i get feedback on this ticket? a simple, clean patch is available, and i don't understand what is blocking it.

I re-tested this with version 2.2.8 and the same result.

For issues/19, it is also reported in T3374: gpg recv-keys fail if first dns server end up with "Connection refused".
This is fixed in master now.
I'm not sure if original reporter's problem is issues/19 or not.

I tested on Debian with local dnsmasq. For usual setting, no problem.
If /etc/resolv.conf has nameserver 127.0.0.1 and the service by dnsmasq somehow stops, and we have another nameserver nameserver somewhere-not-local the issues/19 matters.

I've made the parsing less strict in LibTMCG: https://github.com/HeikoStamer/libtmcg/commit/be7963b33cf8bace9d031074521acc4e89930d33

thanks, that works for me. I look forward to seeing the patches :)

Although "certificate" is used for OpenPGP revocations, it is technically a signature.

can you let me know what you're planning so i can plan my work on enigmail?

thus far every packet type has been a three-letter string, right? I'm looking at "Field 1" in doc/DETAILS. adding a 4-letter packet type seems like it could be trouble if someone has done the dumb thing of assuming the field is fixed-length.

What about another record type for standalone revocations, something line "rev0" or "revx"? This would solve the problem on how to distinguish merged revocation signatures (ie with a preceding "pub") from standalone revocations.

can i get a confirmation that the options you're considering for --with-colons --show-keys when confronted with a revocation certificate will be either:

By "dummy pub line" I think you're proposing output that looks something like this instead of just the rev: line.:

As long as we don't check the signature we don't need the pubkey. That would make it actually easier becuase we have only one case and not 3 or more (bad signature, no pubkey, etc).

Revocation certificates consist of *only* the revocation packet, right? Claiming that the revocation cert contains more than the revocation packet (when it doesn't) seems more troubling from an API perspective than just telling people to expect a single rev: line if they are looking at a revocation certificate.

thanks for looking into this so quickly. where is your patch? i don't see it on the master branch yet.

That will be a bit of work. We can't list a standalone key yet because the the key listing code expects a public or secret key as first packet. Further it would be advisable to insert a dummy "pub" key record before the "rev" record because the advise as always been to use "pub" or "sec" as start of a key keyblock.

Thanks for reporting and your patch. However, I used a different way to solve this bug.

Thanks. Pushed to master. I think it should also go into 2.2.

I've just pushed e037657edaf0b3ee9d2e30f6fe3edf6879976472 on the fix-T4019 branch

I've heard no critique of the logic above. could we get this fix landed? it is concretely useful for doing key generation on modern GNU/Linux systems.

Unfortunately 2.2.8 does not build with older libgpg-error versions. Commit rG18274db32b5dea7fe8db67043a787578c975de4d should fix this.

2.2.8. with a fix has been released. Announcement

[Better use the gnupg tag. Specific versions end up on the workboard and there may only be one.]

BTW, you now need to use --rfc2440 to create a non-mdc message for testing.

It's nice. Although for now I've only added a message in the legacy_cipher_nomdc case:

I justed commited some gadgets to gpgme which might be helpful But please show warnings etc before you use that new option.

I wonder if there's potential for engaging users remotely? Also, in addition to a workshop, maybe a user interface study of how users learn and interact with the tool? I feel like doing that with people who are relatively light/new users of gpg (like me, currently struggling as I wade thru a mix of docs, some of it outdated) could be beneficial. See also: https://arxiv.org/abs/1510.08555

please see the branch dkg/fix-T3995 with rG3308d5e3f4e25dce5168c4a7cb2f545424c6d185

But why is that the case for OpenPGP Signatures, then? The difference does not make sense to me.

The key receives fully trust and thus we get the "green" flag plus the "expired" flag. In my test with OpenPGP the key was not trysted and thus we did not got only the "expired" flag. At some distant past we agreed on these rules.

gpgsm behaves exactly as gpg and as explain in doc/DETAILS. VALIDSIG is issues even for signatures done by an expired certificate. Let me check whey GPGME claims "green" here while it does not not an expired OpenPGP signature.

Wait. Users should not have the ability in the GUI to mess with the CRL cache. That is internal / private stuff. And something for developers, so this should be removed from the GUI altogether.

I think this issue is important as GPGME should not report "Green" / Everything OK in that case and only have the EXPKEYSIG in details.

The semantics of --list-only are not well defined. Needs some overhaul.

See also Filippo Valsorda's 32c3 talk about CSPRNGs.

@gouttegd : setting only-urandom at the distro level problematic due to two factors:

@dkg : Can’t this be solved at the distribution level? I assume the packager/maintainer for Libgcrypt on a given distribution should know whether the getrandom syscall is available on said distribution, so he could install a /etc/gcrypt/random.conf file with the only-urandom option.

Werner wrote:

we already use the getrandom system call if it is available

3.1.0 is released and this issue is to our knowledge fixed.

To clarify: We already use the getrandom system call if it is available. To map /dev/random to /dev/urandom you can create a file /etc/gcrypt/random.conf with this line:

You are right in that enigmail uses no-auto-check-trustdb

As far as I understand your comment there is already a timeout of 15s per connection. But as you wrote, it doesn't fit all cases. In my case, gpg.exe just stayed open indefinitely.

man dirmngr

Is there any ETA for when this might get fixed? We are having the same issue with our keyserver since it's behind a cname.

@dkg thanks for the link.

The severe delay caused by check-trustdb continues to cause problems elsewhere in the ecosystem. It would be great to try to address this so that GnuPG was more responsive for routine tasks like importing a single key.