We can later decide whether to backport this to 2.2

For workaround (master branch with rG0a7661129499), moving the private key file to *.key.bak can do that.

But not for 2.2

I've changed the text of this report from "filter" to "screener" to match the preferred terminology. thanks for the clarification.

I still consider the import screener (the term filter is used in a different way now) a big mess. Using the import feature to maintain the idea of a curated keyring is a bad idea because gpg has not been designed with this in mind. We spent so much time on this screener already and problems pop up again and again.

I am not proposing changing the order of the *hashed* subpackets in a signature. I'm proposing removing/changing/canonicalizing the *unhashed* subpackets in a signature. Sorry if i didn't make that clear enough in the initial message.

But wait. Does my idea really help with comparing? I doubt it because a signature also includes a date and other variable stuff and thus they are already binary identical or it is a different signature.

Right we can't change the order of signature subpackets after they have been created. Given that we create subpackets by directly appending them to a memory buffer instead of keeping a list of subpackets to create, the least invasive method would be a function to shuffle that memory buffer right before the signature is computed.

I thoroughly agree that this is not required by the specs.

That is not required by the specs. Another way is to provide a tool to compare keys. That seems to be easier to me. Also consider the cases that there are new new packets or signature subpackets with unknown properties to the current implementations. What about different encodings in signed key material?

This would emit the "content-encryption key", as specified in
https://tools.ietf.org/html/rfc5652#section-6.3