update for gnupg po/zh_CN.po
D518: po: Update Simplified Chinese translation po/zh_CN.po
the update is so big, so please review when you are free, and do not be push
thanks for all help

Hope he/she could help with that.

In T5189#140669, @gniibe wrote:

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

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..

GnuPG requires some C99 features - thus a language level of C89 might not work. We use variadic macros and the func macro. For details see doc/HACKING.

OS:AIX , Compiler: XLC

Pushed the change for libgpg-error zh_CN.po.

For PO file editing, what I use (for Japanese Translation) is:

• Emacs PO mode: https://www.emacswiki.org/emacs/PoMode

There are actually tools for PO file editing:
http://docs.translatehouse.org/projects/localization-guide/en/latest/guide/tools/trans_editors.html

Thank you for your effort. I'll review.

patch of libgpg-error/po/zh_CN.po
D516: po: Update simplified Chinese translation po/zh_CN.po

In T5189#140595, @gniibe wrote:

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

Sorry, in case you already know that.

May I ask that how to get a new complete clean po file.
I'm not familiar with gettext.
The old one is confusing, and I think maybe I should completely clean the messy.
Really a big project.

Frankly, I more or less forgot about these help files. The German version for sure needs an update as weel.

In T5189#140595, @gniibe wrote:

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

Sorry, in case you already know that.

In T5189#140594, @gniibe wrote:

For D515, I will also apply it to master.

Before that, I'd like to confirm an editorial change of mine:

• Remove an extra space before new line (two places)

Please and thanks, I imitated the English edition format :-)

• Remove a comment for use case of the file
  • If needed, we could have support of another locale(s) with Chinese language: zh_HK, zh_SG, etc.
  • It is not us, but it's users who decide which locale is better for them
    • E.g., my friend in Düsseldorf uses ja_JP locale
  • So, it's technically better not to address restriction in a translation

for that, I think you best keep that.
Use a locale to distinguish Chinese users always cause problems.
There isn't a big difference between the written language. And small region always lack translations.
Singapore's users who use simplified Chinese always use zh_CN if there is no a specific zh_SG.
And the traditional Chinese users from HK SAR and MC SAR sometimes use the translation for Taiwan Province.
So when translate it, the tip remiand you must consider all the users from anywhere.

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).

also update doc/help.zh_TW.txt by the way
D515: update gnupg doc/help.zh_TW.txt

Yes, that worked. Thanks for the tip and sorry for the noise ;-)

upload the v2 patch and create a revision
D514: update gnupg doc/help.zh_CN.txt
waiting for review
:-)

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:

In T5189#140362, @gniibe wrote:

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.

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.

OS, Compiler, any configure options?

In a discussion we decided that we need a deadline for GnuPG 2.3.0 so that we finally release it.

In T2291#140172, @gniibe wrote:

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

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.

Report on some testing using master:

See the release info over at T5052 which notes the problem. See T5140 for details and update to 2.2.25.

Backported.

We need another patch, because there are two places for gpg --card-edit and gpg-card to check OpenPGPcard's version number if it's >= 2 or not.

Perhaps of interest for this issue: the HKPS pool has consisted of only a single server for a couple of months now.

In T2291#139821, @lopter wrote:

if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

Thank you for all the work! Does it mean that, if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

Fixed in master. I will backport to 2.2.

This has been fixed for Unix on 2.2 and 2.3. The command line fix for Windows is a larger thing already tracked by T4398.

We changed the fallback to utf-8 in 2.2 and 2.3 and thus this bug can be closed. On Windows there is still the problem with the command line. However, this is better tracked with T5038 and its related tasks.

Finally, with the physical device, I figure out what's going on.
The error handling in bulk_in in ccid-driver.c is not good for pinpad input.
It doesn't return an error when it is cancelled or timeout (for the user interaction).
And it calls libusb_clear_hald which causes screwed up situation.

Sorry, I realized this myself this morning and did couple of fixes. rG7113263a00d8 does this all however I forgot to mention the bug number.

Argh. The following patch replaces the previous patch. It fixes the calculation of the display serial number.

I think the calculation of the OpenPGP s/n is not correct. As you write, "Yubico seems to use the decimalized version of their S/N as the OpenPGP card S/N." This matches my observation for my Yubikey:
s/n printed on Yubikey: 9074582
Yubikey s/n (with our prefix): FF020001008A7796
OpenPGP AID: D2760001240102010006090745820000

Great. Please apply the patch.

Okay, I now got such a patch:

I found a good enough solution: I changed the code to compute the OpenPGP s/n from the Yubikey s/n right after a Yubikey has been detected. Later, and if OpenPGP enabled on the YK, the S/N is already there but we use the S/N from the 0x4f DO. That is needed because we can't compute the OpenPGP version number ahead and use 0.0 in the S/N.

Please use shorter password.
For gpgsm, maximum is 31 chars.

Removing 2.2 tag because it has been fixed in one of the last releases.

Its done for 2.2 thus changing the tag.

How about distinguishing CARDNO and application specific SERIALNO?

A fix has been released; see T5052.

BTW, the idea is to fade out support for gpg --card-status and --card-edit. Thus no new features there. New features shall only go into gpg-card.

Fixing --card-status is definitely a good idea. gpg-card shows almost the same information as gpg --card-status except that it shows the correct "Version" and "Serial number". It would probably make sense to unify the code of --card-status and gpg-card's list command.

Let me describe current situation.

I just noticed that gpg --card-status now prints a bogus OpenPGP version number for my Yubikey. And it prints an empty serial number.

# gpg --card-status
Reader ...........: 1050:0407:X:0
Application ID ...: FF020001008A7796
Application type .: OpenPGP
Version ..........: 77.96
Manufacturer .....: Yubico
Serial number ....:

"Revoke Certification(s)" is available in

• Certifications Overview as context menu option for the user IDs
• Certifications Overview as context menu option for the signatures
• Certificate Details as context menu option for the user IDs
• Certificate Overview (aka key list) as context menu option for keys
• Certificate Overview (aka key list) as menu entry of Certificates menu

For 2.2, rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN. fixed this problem.

It's fixed in master by T3465: --pinentry-mode loopback with --delete-secret-keys, with new confirmation interaction.
For 2.2, you can use --batch and --yes, see T4667: "gpg: deleting secret key failed: No pinentry" when in --batch mode with --pinentry=loopback.

Note: menu_backsign can be enhanced to detect such a case in the same way it detects missing backsigs.

We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.

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 have tested this with Kleopatra. The good news is that SCD GETATTR $DISPSERIALNO now works for the piv app even if the openpgp app is enabled.

Unfortunately this new release has a regression affecting users with non-ascii account names. See T5098.