For a bug which requires more tests (like this one with GnuPG and pinentry), I had a practice to put "Testing" tag.

Note that even after rCce1cbe16992a: Disable non-allowed algorithms in FIPS mode, gcry_md_open won't return an error with disabled algo.

The changelog in https://src.fedoraproject.org/rpms/libgcrypt/c/402a3b5f2eed746bea996c5743c99bec9bbc3487?branch=master

For printing SEXP, it would be good to have this change:

rG47c1c329ed82: agent,ecc: Use of opaque MPI for ECC, fixup 'd'. does the fixup when reading keys.

I describe about rC6f8b1d4cb798: ecc: Consistently handle parameters as unsigned value..

Reading compressed point (in keys) is supported (except for NIST P-224). When curve point is represented in compressed format, it is correctly interpreted now. So, for example, I think that with 1.9.0, gpgsm can handle certificate which uses compressed format in its curve point representation.

D520 is accepted by me.
If you will have another fixes, please go ahead.
Or else, I'll commit the change to master of GnuPG.

rG6850f21d08b2: po: Fix Simplified Chinese Translation. is a fix for adjusting columns; The number means the number of columns.
rGf4a8be0950ea: po: Fix Simplified Chinese Translation. is a fix for:

• SETERROR is a command name of pinentry which should not be translated.
• The message is expected to be displayed in four lines.

Please check following translations:

"do not detach from the console"
"do not use the internal CCID driver"
"do not use a reader's pinpad"

Those are explanation for the options to instruct gpg-agent or scdaemon, not do something.
It's not a text to users.

Sorry, I didn't read your message above, and it's applied and pushed to master, due to exactly same reason (it's so big).
It's easier (at least for me), when it's in git repo.

For D515, I think that there is similar issue, and I received another patch from Debian.

Reviewed D517 and pushed it as rE621446d3c859: po: Update Traditional Chinese Translation..

I did editorial change for meta data.
Also, I fixed the translation of "out of core", even if it's unused (it's comment).

Pushed the change for libgpg-error zh_CN.po.

I think that you don't use PO editor. I'm going to remove mark like ", fuzzy", which should be removed when entering good entry.

Thank you for your effort. I'll review.

Please note that many error messages are defined in: https://dev.gnupg.org/source/libgpg-error/browse/master/po/zh_CN.po
and https://dev.gnupg.org/source/gnupg/browse/master/po/zh_CN.po

For D515, I will also apply it to master.

Applied D514 to master, with an editorial change (removing extra space before newline).

Please change your passphrase for your card, BTW.

Good. The error recovery worked well.

Translation of "key" is difficult in our context of public key cryptography.
In many case "key" just refers public key, but for key generation, it means key pair.

Please not that you can use this interface: https://dev.gnupg.org/differential/
I think that it is better when you update your patch. You can just refer a patch from this task by:

If translated, 'keygrip' should be different word to 'fingerprint', because 'fingerprint' is used as a technical term of OpenPGP.

Do you call gpg-agent as 'Gpg 代理'? IIUC, it is better keep it as is (gpg-agent), because it is the name of the program.

I think that ... For some reason, your private key file under .gnupg/private-keys-v1.d has wrong serial number.

Thank you for your testing.
May I ask more test, please?

IIUC, for completeness, it would be good to add the lines like:

I cannot find good test vectors for PBKDF2 with HMAC-SHA-2.

In T5167#140229, @gbschenkel wrote:

Nice, I gonna apply the patch and see if resolves for me!

If your problem is the incompatibility between standard OpenSSH (server) and PKIXSSH (client) for use of ssh-agent emulation of gpg-agent with ECDSA key, I'd suggest to apply following patch to your PKIXSSH:

diff --git a/compat.c b/compat.c
index fe71951..0c9b1ef 100644
--- a/compat.c
+++ b/compat.c
@@ -245,7 +245,6 @@ xkey_compatibility(const char *remote_version) {
 {	static sshx_compatibility info[] = {
 		{ 0, "OpenSSH*PKIX[??.*" /* 10.+ first correct */ },
 		{ 0, "OpenSSH*PKIX[X.*" /* developlement */ },
-		{ 1, "OpenSSH*" /* PKIX pre 10.0 */ },
 		{ 1, "SecureNetTerm-3.1" /* same as PKIX pre 10.0 */},
 		{ 0, NULL } };
 	p = xkey_compatibility_find(remote_version, info);

Our tests are now in tests/basic.c.

For CMAC tests, we would need to use newer test vectors.

Unfortunately and confusingly, PKISSH returns "OpenSSH" when asked by "ssh -V".
Please install real OpenSSH, if this is the case for you.

I added "Feature Request", because this is a request to support:

• A feature of bug compatibility, which is implemented wrongly in PKISSH
• for a specific algo of key, which is not considered so useful (== ECDSA)
• PKISSH, which is variant of OpenSSH

In T4563#140184, @idl0r wrote:

I was and I am using OpenSSH on both sides, client and server.

In theory, I don't think the patch gnupg.patch works. It just ignore the flag.

Thank you for testing.
For the issue #1, I think it is the probelm of rG1cd615afe301: gpg,card: Allow no version information of Yubikey., which is fixed already. This was introduced by the support of PIV feature of Yubikey.

Reading the code again, I think that some configuration of NKS card doesn't work well, when it has no certificates but keys (e.g. IDLM config).
I'm going to fix do_readkey as well (the approach #1).

With my Yubikey NEO, when I use OTP (touching the button to generate OTP output as key input), I observed "card eject" event:

2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: interrupt callback 0 (2)
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: NotifySlotChange: 02
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: card removed
2020-12-10 11:23:05 scdaemon[7254] DBG: enter: apdu_get_status: slot=0 hang=0
2020-12-10 11:23:05 scdaemon[7254] DBG: leave: apdu_get_status => sw=0x1000c status=0
2020-12-10 11:23:05 scdaemon[7254] DBG: Removal of a card: 0

Thanks a lot for your time to locate the problem. I took the approach of #2.