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

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/

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

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.

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.

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

Thanks for the writeup. Maybe this could be the base for a gnupg.org/blog article.

So we had two releases with the fist. Can we set this bug to resolved?

I was not aware that you could do this at all. You are right in that to start supporting this we first need to update libksba.

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

@dkg can you please take this up with Debian and other distros? See the commit for a brief description.

Fixed in 1.4, 2.2 and master. New releases will be done soon. Note that there is no need for a new gpg4win release because GPGME is not affected.

Okay. Thanks for looking into this.