Great. Let me know when the newest gpg4win is released.

(fwiw, all of this testing is done with GnuPG 2.2.14-1, using the package that is in debian/experimental right now; i'd welcome any corroboration with other versions)

as i experiment with this, i find an even weirder result with certificate re-ordering: the function above is not idempotent.

Here is a horrible bash function for doing the kind of stripping and re-importing that *does* cause signature re-ordering:

werner wrote:

Great. Thank you.

We are aiming for this week.

When will the new gnupg program be released so I can install it?

Charles

So where can I get the corrected file to install? I suppose I need the
new gpg4win, it hasn't been updated yet. If I need the signature or TAR
from your website how can I implement that?

Charles

Where can I get the new thing file to install?

Thanks! I've confirmed that it works for me.

The secret import code actually had a bug in that it silently imported the secret key anyway, so that after importing the public key the secret key showed up. That was not intended because we do not want to allow importing arbitrary keys or subkeys if the don't have a corresponding public (sub)key with the mandatory key-binding signature. This has now been fixed. A fix for the actual problem will come soon.

Ok. Let me know so I can try it out.

Yes, I think that if I see an import result with "secret-keys-read && w/o userId's" I can just do a second try.

Checking the OpenPGP specs again, there is actually an "exit" clause for this PGP bug. Or well, what I would consider to be a bug. A fix for this is not easy because it would require to detect this at an outer level (the ascii armor) which we don't do because gpg is build along a streaming concept as almost all Unix tools. What we can do is to allow import of a secret key in that PGP format iff a public key is already there. In practise this would mean to run the import two times and ignore the errors from the first import.

I meant the abbreviations. PGP is based on a code base dating back to 1992; for example we mostly used the term keyblock instead of certificate in the code.

Those terms are not arbitrary, they are in the RFC.

Thanks. [I wonder why the looong established terms public-keyblock and key-signature must be replace by arbitrary new terms.]

• TPK: transferable public key
• TPS: Third-party signature

Thank you very much for the analysis. I'll forward the info.

The creating software is broken in regard to non-ASCII characters in the UID:

Good idea.