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

see e051c279216ecd4ec9a48e13ccc695f5ab667b2a

I note that --import-options show-only --import has the same effect as --show-keys -- that is, the revocation cert is imported. so the error is in the import-options code itself. I'll push a fix-T4017 branch shortly with a proposed correction.

I just noticed, that a tag for Libgcrypt 1.8.3 seems to be missing: https://dev.gnupg.org/source/libgcrypt/tags/LIBGCRYPT-1.8-BRANCH/

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

Here is what we have now. We decided explictly not to offer a "yes I want to do something less secure" button as we think that using Unsigned S/MIME Mails is avoidable. Also we want to be more secure by default then Outlook. From a User Experience standpoint a "Yes more convenient but less secure" button basically educates users to always select that button.

Yes, closing.

I'm having the same issue. I read somewhere that it's likely caused by using an online Windows account to login with. So I converted to local log in. Issue persists. As a test, I've just set up a VM with a local account set up at install, and GPG4Win works perfectly fine. So I'm guessing that there may be an issue which stays in the files system caused by online account users. I'm not a programmer and have no idea how or where to look to see what's causing it and how to fix it though.