That was my fault in commit rG8fc9de8d6bf663f7c8419b42dab01f590a694d59 obviously I assumed that the macros were always used.

I see the reason.

@aheinecke as promised, attached some test vectors:

FWIW: These days a thread on Linux is not that costly but nevertheless takes up resources. On other Unices (and WindowsCE) threads have quite some overhead and that was the reason I implemented it the way it was.

I made a clean install of the system and installed gnupg from sources. Now it works strangely.

This has always worked on the client site since we implemented keyserver access.

Omnikey readers only work properly on Windows because the Windows driver uses proprietary extension to make it work. Better don't use them. In case you want to look at details, add

I see no problem to return only revocation packets. Clients must verify them anyway against their public keys and the fingerprint makes this easy. Verification against a primary key delivered along the revocation is more or less useless because that primary key must anyway been looked up in the client's keyring and th local existance of a primary key is anyway required to ask a keyserver for a revocation.

The trick here is that during import gpg tracks those invalid signatures and then tries to apply them to other keys.

Appended. Yes, it is considered an invalid signature and ignored. Anyone can insert an invalid signature. The trick here is that during import gpg tracks those invalid signatures and then tries to apply them to other keys. The use case here is this:

If you need the fingerprint, why don't you take it from the revocation certificate - for many years it is in subpacket 33.

In T6900#180549, @andrewgdotcom wrote:

Hi, Andre.
...

Thanks for the explanation. To me this sounds very reasonable and I think that I am starting to better understand your use case in Hockeypuck.
Having a test example key + the intended revocation update would help at least me to dig into it a bit and see how this might conflict with RFC4880.

I'm curious about the parsing implications of this bit:

Well, the quoted paragraph ended with a

Individual UID revocation sigs are not particularly useful, because they cannot be validated without the original UID. Such things are out of scope.

Hi,
so I talked to werner about this, and of course GnuPG accepts minimal revocations.
A revocation certificate. So that was my point. As he understood you, you wanted to revoke not the whole key but only a single user id but without the user id packet? Sorry I am not really the protocol expert. But for me a revoked key without any user ids sounds to me just like a "standard" revocation certificate revoking the whole key. And as said, that is well within the the Standard and accepted, and even used by GnuPG. E.g. in case of a keyrollover we attach such a minimal revocation certificate to WKD keys when we deliver key updates.

In T5709#180540, @bernhard wrote:

Would it be a workaround idea to double the attachments, so that the original ones would be used as reference for embedded viewing? And the other to be shown?

Yes they can, the workaround, which GpgOL even suggests in the error message is that the mail may not be visible as plain text while changing flags or categories. This usually means that you have to select a different mail and then use right click on the mail you wish to mark for followup or add a category to. The whole problem is that while the plaintext is visible in Outlook we have to prevent changes to the mail from beeing synced to the server or otherwise it will also sync the plaintext.

A user also report this problem with Microsoft365 and Outlook Versions 2302 and 2208. (Exchange is the latest online-Version.
Assuming current Gpg4win v4.2.0)

In T6891#180473, @aheinecke wrote:

@ebo told me that she can reproduce the problem by just moving around e.g. 1000 unread mails to a different folder and then e.g. marking them all as read while they are syncing. At least if I understood her correctly. @ebo could you please describe your test case?

A user also report this problem with Microsoft365 and Outlook Versions 2302 and 2208. (Exchange is the latest online-Version.)

Would it be a workaround idea to double the attachments, so that the original ones would be used as reference for embedded viewing? And the other to be shown?

From a technical standpoint I think the most minimal revocations which are technically possible should be accepted and thus I endorse the feature request.

In any case this is technically required

Actually the public key is personalized data as much as a mail address. In any case this is technically required and users take an informed decisions when they distribute their public key to a site not controlled by them.

It looks that this is a bit more problematic case than I thought. Now building i386 with "-O2 -fsanitize=undefined" flags fails. I need to think little bit more how to handle this.