Some ideas:

• the someflags thing will probably just be a reserved parameter
• If DATA is not NULL but an MD is set the sign function should fail
• Should ownership of MD be moved to the CTX?

CC does not offer such an option as the GPL does.

FWIW, there is also this newer patch: https://dev.gnupg.org/differential/diff/1476/
and SUSE seems to already use a modified API:
https://sources.suse.com/SUSE:Maintenance:15118/libgcrypt.SUSE_SLE-15_Update/26a8df5f96d27d6abca7bd7ba9b0def0/libgcrypt-FIPS-RSA-DSA-ECDSA-hashing-operation.patch

Our public key functions are stateless. For several reasons it would be good to have an option to keep some state (think pre-computations). Our gcry_ctx_t would be a perfect fit for this and it will allow us to join a pubkey function with for example a hash function.

Fix will eventually go into 2.2.29. If there is enough public demand we will do a new Windows installer earlier.

Check out https://gnupg.org

Thanks. Commited as rG755a5f1a0e3

The private key contains the public key. Thus there is no need to export the public key if you already got the secret key.

No, sorry. For help please use one of the mailing lists.

Clone and checkout the branch as usual with Git. There is no web editor etc like you might know from github. For your request we need to wait for someone to check your request.

2.2.23 is an old version. We will soon release 2.2.28 which comes with an updated Simplified Chinese Translation, see rGb0a7132856

Now also fixed for 2.2.28

Better don't backport this.

FWIW: Actually the old code assumed that the s/n is at least 4 bytes. IIRC, I once checked the source of the Yubico tools to get this info.

I need to see how we can pass the check permission notice up to gpg. This is a too common problem and thus serves some special treatment.

Alright, we can keep just the colon delimited format for --ldapservers et al. Because we support ldap URLs in CrlDistributionPoints in X.509 certificates we need to handle them internally. But there is indeed no need to support them in the config files.

gniibe: Can you explain why an import shall modify the secret key? Form my understanding it is an invalid secret key and thus it can't be used. An import operation is different than the key generation.

Please read T5454 again. To get the listing I showed you need to use the latest gpgme from Git master.