Actually we considerto remove this feature from the GUI because with the global config we have a more versatile feature now.

Won't be done because the expectations of users are different on whether they use ssh-agent or gpg-agent. And it breaks scripts

Done. FWIW. in 2.3 symcryptrun will be removed entirely.

See also https://gitlab.com/openpgp-wg/webkey-directory/-/issues/3 which is the same issue.

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:

This ambiguity appears to be the cause of a recent epic (and to me, largely incomprehensible) thread on gnupg-users. It would be great to have the WKD guidance about fallback strategy be much more explicit. Any room for ambiguity here leads to different outcomes from different WKD clients, and quite a bit of confused discussion by their users.

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

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.

Thanks.

Read through it, thanks for the updated description!

Thanks. Fixed for 2.2.22

No info received

Done.

Okay, makes sense.

No, it is widely understood as a means for reproducible builds and specified at: https://reproducible-builds.org/docs/source-date-epoch/

SOURCE_DATE_EPOCH is NixOS specific?

Well, I had simply accepted that the rule for defsincdate is always triggered. I looked a bit more into it, and the cause for triggering is that Nixpkgs patches dirmngr.texi, hence defsincdate is cleared by the rule above and the fallback behaviour is triggered.
But this also means my suggested patch wouldn't help here as the modification date of dirmngr.texi would be picked up.

Looking at the rules I do not understand why we have a problem here, the rule

I think an option to ignore certain files is a better way to do this. I'll give it a try.

Cool. Falls du einen Korrekturleser für die neue Fassung brauchst, sag gerne Bescheid. Ich hab da Erfahrung …

erstmal vielen dank für das Feedback. Ich habe momentan als Aufgabe ein neues Benutzerhandbuch auf Basis des Kompendiums zu erstellen und werde da die Hinweise auch mit Aufnehmen. Technisch ist sowohl der Inhalt als auch die Art wie das Handbuch erzeugt wird nicht mehr aktuell, wir brauchen da dringend etwas neues das wir auch online stellen können.
Sollte noch in diesem Jahr passieren.

Thanks for the patch, applied!
You are correct the NEWS file states that this was added in 1.9.0

@sarman: Your question is actually a support question and not a bug report. Please read the documentation, use the public help channels (so that other can also learn from the issue), or get in touch with a commercial support provider.

I think that what you want is adding --batch option. In the gpg manual, we have:

--passphrase-file file
       Read  the passphrase from file file. Only the first line will be
       read from  file  file.  This  can  only  be  used  if  only  one
       passphrase is supplied. Obviously, a passphrase stored in a file
       is of questionable security if other users can read  this  file.
       Don't use this option if you can avoid it.

Hello Team,

For operations which require private key, it is needed to unlock private key.

Thanks. Fixed in stanble and master.

This was already fixed with version 2.2.5.

This was also raised for (hopefully) wider discussion on the IETF mailing list.

I am in charge of editing the current OpenPGP draft, so I will for sure keep an eye on that issue. If would appreciate if you can post your report also to openpgp at ietf org.

Thanks, fixed in master.

I disabled the dependency rules for the figures (it's only enabled for maintainers).

Given the recent problems with the keyservers, I expect that the keyserver feature will go away anyway and thus I do not think we will put any more effort into this. Thus I re-tag this as gpg 2.3.

If we only need it for backward compatibility, then the configuration in gpg.conf should *not* be overriding the preferred, forward-looking form of the configuration (in dirmngr.conf). If it is low priority to fix this, then there will be a generation of GnuPG users and toolchains which deliberately configure the value in gpg.conf instead of dirmngr.conf because they'll know that's the more robust way to do it.

We need --keyserver in gpg for just one reason: backward compatibility.

thanks for fixing that error message, @werner. As @Valodim points out in discusson about hagrid, a gpg.conf keyserver option (deprecated according to the documentation) overrides the dirmngr.conf keyserver option (not deprecated according to the documentation.

I see the regression of gpgconf. I wonder if it's better to fix gpgconf side, too.

I see a regression with your fix. This option is even controllable with gpgconf at the basic level. It would be better to make it a dummy option.

I meant, 'card-timeout' was not intended for controlling caching PIN on card. It was for "DISCONNECT" command support.
I'm going to remove questionable documentation.
Closing.