Fixed for master and 2.2.9.

We didn't found the time to organize it. There will be a OpenPGP summit this fall organized by Patrick, though

Will be released with 2.2.9

Fix will also go into 2.2.9

This is really minor, just wanted to report it so it did not get forgotten.

Backport done. To be released with 2.2.9.

User input, anything to solve the lack of entropy on servers would be *great*. We have a bunch of buildbot workers we would *love* to have sign their artifacts... however we end up (unsuccessfully) doing stupid things like this to try and drive up entropy as a non-root user:

Looking at the table in random(7) it seems clear to me that what we want to just invoke getrandom() with no arguments. This blocks until the kernel's PRNG has been adequately seeded, but once seeded it doesn't block, while still pulling from an unbreakably-strong PRNG. this is the best-of-both-worlds situation that we want.

Changing the GnuPG long-term (and short-term) key generation techniques to use this approach might require coordination with gcrypt. gcrypt's gcry_random_level currently has GCRY_WEAK_RANDOM and GCRY_STRONG_RANDOM and GCRY_VERY_STRONG_RANDOM, which doesn't represent the nuance described above.

One approach might be to just have gcrypt on Linux treat all values of gcry_random_level the same, and use getrandom() for all of them.

ping again…

Maybe a first step would be a "KEYLIST_MODE_WKD" which sets "auto-key-locate clear,nodefault,wkd" (Would be nice for T3910 ) or just a ctx_flag "auto-key-locate" so that the caller can decide?

The cause is: ! in nsswitch.conf
This was fixed (2.2 branch) by rGd4c0187dd931: libdns: Hack to skip negation term. for GnuPG in Jan 2017.
I found it was fixed in the original libdns, and this fix is merged into rG20c289606f89: libdns: Sync to upstream. to GnuPG.

Done for master. Needs backport.

I implemented it in master and if you agree I will backport it to stable. This is the new output:

We should include the man page then in texi format into tools.texi

I manually configure IPv6 only environment, and now (forthcoming 2.2.9), it works fine for me.
So, I move this state to Testing.

• dirmngr fix for --recursive-resolver: rG5b40338f1276: dirmngr: Fix recursive resolver mode.
  • After the release, we can ask using this mode not to use nameserver in /etc/resolv.con, but resolve by libdns directly
  • Possibly, these bug reports are related: T2968: gpg --search: Connection closed in DNS, T3168: dirmngr: gpg: keyserver receive failed: No keyserver available, T3517: dirmngr: retry without SRV due to buggy routers

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