Considering the history of the translation, I concluded that it should be:
把密钥导出到一个公钥服务器上
(the typo was G-A where B-A was expected.)

@guzhongren
This is not GitHub, so, if you want, you need to learn how to submit your change in the form of patch, by using git.

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.

Now also fixed for 2.2.28

Better don't backport this.

Fixed.
I'm not sure if it's worth backporting this to 2.2.

I encountered this bug last year, but I realized that it's hard to make a reproducible case.

In your log, it says:

usb_claim_interface failed: -3

Sorry, I was wrong.

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.

GPG Version :

In T5442#146871, @gniibe wrote:

I see your situation

Could you please help me to analyze what's going on?
Please add following lines to your scdaemon.conf to see CCID driver's debug output:

debug-ccid-driver
verbose
verbose
verbose

And share the debug output.

Ah, I think that your problem was fixed in rG53bdc6288f9b: scd: Recover the partial match for PORTSTR for PC/SC. (to be 2.3.2).

I see your situation

In T5442#146869, @gniibe wrote:

If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?

If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?

Hi Werner, I need this for a potentional customer. And generally I need this in config, too. because in support we have to send customers configuration files which they do not need to edit and variables are important because of file system permissions. But most immedialtely I need this for homedir registry.

jitterentropy is also used in Linux kernel, and some people use clang to build it these days. So, I checked the kernel's one. It is simply compiled -O0 by Makefile, and there's no pragma line now (as of v5.13).

I don't think that it is a good idea to silence this warning. The pragma is esssential for proper random numbers and if clang hijacks a GCC's name space but implements something different it is better to have a warning than to fall into the pit full of dragons.

In T5369#144864, @jukivili wrote:

That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).

I test on ppc64 machine (POWER9, big endian).

Could make --multifile work on windows 10, documenting the workaround here.

This is another test case for GNU C library's strncmp:

This is the minimized test case.

Thanks for the well written report. We had another already, and thus I merged it into T5415.

Frankly, I am pretty sure that the new base64 encoding of the fingerprint leads to less diligent comparison of the fingerprint by the user. I don't understand why they did not used a truncated hex output or zBase32 .

Ah, great. Thanks!

Thank you for taking time to look into that. There are couple of issues in the CAcert bug tracker talking about the same issue but if, (I see right), the certs still miss the usage flags:

RFC-5280 states in 4.2.1.3 for Key Usage:

Any chance looking into this @werner?

The curve is not defined to be used for ECDH (encryption); in fact it should in general only be used with the EdDSA
algorithm. You need to use "Key-Type: eddsa". Note that the EdDSA signing algorithm is different than the commonly used ECDSA signing algorithm.

Thanks for the quick response Werner. I knew I could use it with quick-gen-key and I’ve updated my config file to have it as default.
But, just for my understanding, is there a reason ed25519 cannot be used with full-gen-key and gen-key in batch mode?

You can't use ecdh with ed25519.

Update:
It looks like OpenSSH version 8 now supports ssh-agent's handling REQUEST_IDENTITIES.

it's in 2.3.

This has been fixed in version 2.2.16.

gpg4win 3.1 has no full Unicode support. You may try to install the new GnuPG 2.3 version on top of gpg4win to fix this problem or wait until we have releases gpg4win 4 which will come with GnuPG 2.3.

Done in 2.3.0.

Done in 2.3.0.

Done in 2.3.

This was changed in kleopatra some time ago to also generate keys with 2y expiry. So the motivation for this issue is gone.

Note that rndjent.c is already build with -O0 as can be seen in example above. That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).

Do what ever you want with _gcry prefixed functions - this is never considered an API or ABI break. There are some exceptions for internal functions used by macros but those are clearly marked.

These functions are internal to library and, for example, on linux/windows builds are not externally available.

This patch should work if configure properly detects need for extra underscore on C symbols:

This patch should work if configure properly detects need for extra underscore on C symbols:

Here's the patch I am using for the Apple M1: libgcrypt-darwin.patch. The patch is public domain so anyone is free to use it.

This is kind of a hack, but this patch:

yep, Should be fixed in libgpg-error/src/w32-gettext.c unless we want a way to retrieve the meat data. We can also and faster fix this in gnupg proper.

Example from gpg.c:

ARGPARSE_s_n (oQuiet,	  "quiet",   N_("be somewhat more quiet")),
[...]
ARGPARSE_s_n (oNoGreeting, "no-greeting", "@"),

The quiet option has a human readable description, but the no-greeting option does not have one. Consequently, gpgconf --list-options gpg gives the following result:

[...]
quiet:0:0:be somewhat more quiet:0:0::::
no-greeting:0:3::0:0::::1
[...]

For comparison, on an English Linux system the options also look wrong, i.e. all options that are problematic in the German translation are "raw" option names enclosed in double quotes. It seems that the untranslated description of the options is already missing.

Btw this only occurs for some options:

Things are working out nicely and thus I am convinced that we will miss that whooshing sound the deadline would make as it fly by.

We have used this task for more than the usual release info, thus the new title. We will use
T5343 for the 2.3.0 release info.

I'm sorry, if my wording sounded harsh.

In T1756#143328, @gniibe wrote:

In T1756#131862, @whites11 wrote:

I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

??? Do you understand how ssh keys are handled by ssh client and ssh-agent?

In T1756#131862, @whites11 wrote:

I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

Could you tell what is the status of this ticket? Is it planned for the development?
For some users usage is problematic when there are other readers recognized, provided by the OS or hardware platform, and ordered before the target device which in turn blocks access to it.