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.

The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.

We have the --unwrap option which already does this. The problem here is that an addition compression layer is not removed. Therefore I will rename this report to add a feature strip things down to a signature or literal data packet..

Due to better working timeouts we have mostly soolved these problems,. Further keyservers are not anymore of great use these days.

The other patches don't make sense because of future plans for dirmngr.

I have to leave this as open as this describes a clear issue users expirience in our software. I assign it to me to keep an eye on the issue. Werner and me discussed this issue at length verbally and there won't be a quick fix for the stable branch but we will address this some time in the future, but then not only for 8bit but for full unicode.

I mentioned it several times: It is not sufficient to use some wmain as long as we don't rework the entire spawn machinery in gnupg. libassuan and gpgme. Reading Unicode from the command line would be easy the other things are the real work.

And in fact it was never possible to use 8bit filenames on the command line. The result was not stable and led to non-compatible messages due to the use of native character set instead of proper utf-8. It depended on just too much things.
gpgme-tool or gpgme-json might be useful workaround.

You can use --multifile for this. This reads the filenames from a descriptor or a file. One on the reasons to implement Unicode handling at most places was a request to allow using --multifile as a workaound for the command line limitation..

The last server of the HKPS pool dropped off for several hours yesterday, during which hkps.pool.sks-keyservers.net could not be resolved.

Sorry, we won't apply such changes. A couple of years we did this and all we earned were a few extra bugs aqnd useless diffs. Further many of those changes are in files which will be updated from upstream time to time and your chnages would be lost.

OK, I only edited documents and notes, no code changes.

Thanks. However, we need to go over the list one by one to decide this. For example
"http://gnupg.org/.well-known/openpgpkey/hu/12345678" is actually expected to return a 404 and test code may very well use http:

Hi,
you can close this tickets, the Italian translation has already been uploaded successfully. Don't import anything to GnuPG. Thanks a lot!

We are hoping to have at least a beta release soon with gcrypt 1.9 that we can put in a Gpg4win-4 beta.

I think the main work of listed translation update has been completed, and other minor problems will be corrected in the future patch.

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

I'm also getting this same error with GPG4Win 3.1.14.

Description and translation domain were swapped in 2.2.

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.

In T5189#140853, @gniibe wrote:

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.

I think we can close this one, right?

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.