It appears this issue was first identified and triaged in 2016: T2879
The subkey deletion feature also showed up in other issues since then:

i'm thinking that if the algo parameter to --quick-add-key is a keygrip, then it would find the key directly in the existing keyring(s) and attach it as a new subkey.

Thanks for the explanation.

If the ASN.1 is not from an RFC, then the AUTHORS file should not claim that it is from an RFC.

As this update lists multiple issues and following fixes for them, maybe it was resolved by Microsoft?

Diffs downloaded from the revisions don't include commit messages for some reason. Here are all the commits I submitted for review as patch files with messages:

@werner could you review the patches posted here by @matheusmoreira ? This looks concretely useful, and i would like to have this fixed.

SPARC T4 has crypto instruction set for AES, GCM, SHA1, SHA256, SHA512, Camellia and DES, that can be used from user-space too.

Isn't the Sparc crypto instruction set only available in kernel mode?

As I want to keep this tracker clean I would say this is a Wontfix at least until someone (DKG?) provides an argument what would be gained and why we should do this.

That is not a functional feature request and I see no value in chnaging data structures just for being up to the latest RFC. Actually the ASN.1 is not from an RFC but from a specific X.509 profile. For CMS most parsing is anyway done with handcrafted code.

Mmh no. This needs to go into the resolver. If autoresolve is disabled we also want to have that functionality. Having the ca config in libkleo would also help to use the same values in Kleopatra for a CSR.

This should resolve it.

Well there is nothing specially pythonic about it, it just includes the dirs and not the files:

Argh, that Python specific stuff Ben used is weird and does not fit into the autotools model. Someone(tm) need to have a closer look at it.

The digest algorithm used is computed based on the preferences in the key if encryption is also used. Thus this should always work and any decent key has sha256 in its preferences. In case sha1 has a higher precedence, as seen on old keys, --personal-digest-preferences can be used to prefer sha256. However, it is way better to fix the key. The easisies way to do that is to change the expiration date - then the new standard preferences will be used.

Merged. Thanks again for your work on this.

Thanks for the explanation. That addresses my concerns.

I agree that this is a minor API shift, but i *don't* think it's a security problem, because i was particularly careful to maintain the invariant that decrypt(verify=True) will only ever return valid signatures.