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.

--shows-keys is not a debug command to show the inetrnals of an OpenPGP message. It does the same as creating an empty homedir, importing the keys and running -k. Thus there is no way to get to the internals of an OpenPGP messages.

i'm having trouble just assembling the two signatures over the subkey with 2.2.8 in a single homedir. in particular, when i try to do the following with a new, clean test GNUPGHOME, then i see only one signature on the subkeys afterward:

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 :)

See T4012 for a patch to build with an older libgpg-error.

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?

test after system upgrades

Thanks.
So what I remembered was 1 year and 1 month off the real EOL date.

Here is our announcement: https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/000426.html

https://www.nccgroup.trust/us/our-research/technical-advisory-return-of-the-hidden-number-problem/

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.

Informed Debian security team about our change of libgcrypt.

A new installer for GnuPG with Libgcrypt 1.8.3 is now available.

Change done and pushed already.

Releases are now available. Next task is to build a new GnuPG Windows installer.

1.8.3 and 1.7.10 are now released. Announcement will follow later the day.

Pushed fixes to the repository at 16:00+0900 (09:00+0200). It's 0700Z.

In master, it's

commit 9010d1576e278a4274ad3f4aa15776c28f6ba965
Author: NIIBE Yutaka <gniibe@fsij.org>
Date:   Wed Jun 13 15:28:58 2018 +0900

1.8.3 has not yet been released and thus there is no NEWS entries and there can't be a 1.8.3 tag. You are right that the README still says 1.7. I'll fix that for 1.8.3. Why do you think maintenance of 1.7 stopped; the AUTHORS file and the new EOL statements on the download page say that we are going to maintain it until 2019-06-30.

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:

@tinkerwolf This is weird... I've reinstalled my PC from scratch with an initial account set as local, and was able to set up GPG4Win perfectly fine for the first time on my PC (as I did in the VM). So, set up a VM with an initial account set up from an online account. GPG4Win started up fine... I am now really confused!! Somewhere within the getting set up with an online account, something has to be happening that interferes with dirmngr..
Will investigate further.

@RAmbidge are you able to further test this by using a VM with a MS account? I don't have the means right now, or I'd do it myself.

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

Publication is planned for the 13th, 1500Z

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).

That actually makes sense, because it works fine on my laptop, where it's been a local account from the start, but it's broken on my desktop where it was originally a MS account, but is now local.

Fixed with https://commits.kde.org/libkleo/79f0cb79817e44b4eab864c573740c1501e796bd

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.

ee1fc420fb9741b2cfaea6fa820a00be2923f514 contains a proposed fix for this.

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