You are right, the new 3.4 cards support brainpool curves in addition to the nist curves.
If you mean OpenPGP Card v3 standard, no it did not support cv25519 ed25519, but some other curves up until v3.4. So if there is a specific specification bringing this feature, can you might refer to the specific version? Otherwise, I think this task is still valid.
I remember the problem being the card manufacturers that are not interesting in cv25519 (yet).
Support was added in version 3 card.
Mon, Nov 23
As for renaming "Change Reset Code" to "Set Reset Code", what about "Change PIN" and "Change Admin PIN"? Should they also be renamed? If not, why not? Is there no default reset code? Is there a way to find out whether the reset code has already been set (in which case "change" would be more appropriate than "set")?
This does not work.
Can you be more specific? What doesn't work? Which OS, which version of Kleopatra, what smartcard are you using?
I though about this too but we need to take care about the logging functions of Libgcrypt which are intertwined with nPth (clamp function of libgpg-error).
Thu, Nov 19
Thanks. I understand the situation. Basically, gpg-agent's computation is done by a single thread (in current implementation), although it accepts many requests simultaneously.
Wed, Nov 18
Tue, Nov 17
I change this to a feature request: Allow several processes to run public key decryption using the same set of private keys.
Mon, Nov 16
Sun, Nov 15
I know these troubles.
Sat, Nov 14
Tue, Nov 10
Thanks for addressing this in master.
The feature (better cross compiling) was done in master.
We close this bug report as "Won't fix" since it will never been applied to 2.2.
In newer releases of libgpg-error, libksba, libassuan, libgcrypt, npth and ntbtls, we updated corresponding *.m4, so that we can use new gpgrt-config program only. And gpgrt-config command supports cross compiling and multiarch libraries.
Wed, Nov 4
Tue, Nov 3
FWIW, --enforce-passphrase-constraints does already work for symmetric-only encryption since 2.2.21 (rGae8b88c635424ef3). Thus this bug is actually a feature request to have a separate set of passphrase constraints option for symmetric-only mode.
Mon, Nov 2
Thu, Oct 29
Indeed we need to fix/enhance this to make testing of --quick-revoke-sig easier. See over at T5093
I recall that I had the same bug during development. Must have slipped in again - Good catch.
I have added support for this to gpgme (and gpgme++/qgpgme). See T5094.
By the way, --quick-sign-key after --quick-revoke-sig refuses to recertify the key. -> T4584
There is another problem: Even if the first certification was revoked, trying to add a new certification with --quick-sign-key fails because '"user id" was already signed by key ...'
I found a bug. To reproduce generate a new key, then sign it with another key and then try to quick-revoke the signatures. This fails with "Not signed by you."
On purpose. We actually allow user ids and gpg should somehow reflect this. As requested by you I changed it in the man page to what is suggested.
I've noticed an inconsistency between the command arguments in the man page and in the usage/error message.
Wed, Oct 28
The backend part is ready. Someone(tm) now needs to add it to gpgme. Extending the sign key API might be the best solution.
I was already considering this. I bet some people will view it as a bug if it is possible to add something other than a fingerprint. I'll change it in the man page.
Oct 28 2020
Minor remark: I would change this (in the documentation) to
gpg --quick-revoke-sig fpr fpr-of-signing-key [names]
as for --quick-sign-key, --quick-add-key, and --quick-set-expire, even if USER IDs can be used instead of fingerprints. We shouldn't advertise the usage of USER IDs, if we prefer the users to use the fingerprints. I suggest to also change user-id to fpr in the documentation of --quick-add-uid and --quick-revoke-uid. Using USER IDs for identifying keys is ambiguous and errorprone (e.g. if non-ASCII characters get involved, which, incidentally, is the reason why I started to work on KMail).