Test with beta32

Since rfc2440 the PGP specs say:

I think this is correct even on Unix in case someone really uses /usr/local/etc (which I consider problematic). But for Windows we need to determine this at runtime.

I think this is a matter of imprecise documentation.

So, for the current vsd docs (3.3): https://gnupg.com/vsd/kleopatra-settings.html
This would be more correct, if i understood it right?

HKEY_LOCAL_MACHINE\Software\Wow6432node\GNU\Kleopatra
HKEY_CURRENT_USER\Software\Wow6432node\GNU\Kleopatra

My point about action restrictions was to add one sentence in the docs section to clarify, what exactly is restricted then.

I think there is a misconception about Action Restrictions. Yes, they exclusively disable the corresponding action, i.e. the action is hidden and the keyboard shortcuts won't do anything. Action restrictions are no means to disable certain functionality as a whole like "Add User ID". Just because somebody listed all available actions in the documentation (which is rather questionable in my opinion) doesn't mean that it makes sense to remove those actions. Maybe only relevant/important actions should be listed so that the readers are not drowned in a huge list of largely irrelevant settings.

For settings in VSD 3.x best look at https://dev.gnupg.org/source/kleo/browse/gpg4win%252F24.05/src/kcfg/settings.kcfg (gpg4win/24.05 branch).

This looks questionable:

HKEY_LOCAL_MACHINE\Software\Wow6432node\GNU\Kleopatra
HKEY_CURRENT_USER\Software\GNU\Kleopatra

Either both keys use the 32-bit compatibility path Wow6432node\ or both keys don't. 32-bit builds (like VSD 3.x) will use the compatibility path (without being aware of the redirection). 64-bit builds (like Gpg4win 5.x) don't use it. Since Windows mirrors some settings between both registry paths it may not matter.

Allright, then the dash notation for those two groups are intended and the documentation needs to be adjusted

I suspect that the author of the documentation confused the (internally used) "name" of the settings with the "key" that's used in the config files (and the registry). For reference: Many settings are defined in https://dev.gnupg.org/source/kleo/browse/master/src/kcfg/settings.kcfg .

Fixed. Kleopatra and the GnuPG System configuration and error messages coming from GnuPG should now always use the configured Windows display language regardless of the Preferred languages or the Regional format. (GnuPG on the command line will still use the Regional format.)

Note: The tab name is displayed after restart, if

• The tab was renamed manually
• The filter was changed (leading to a rename)

For gpgrt/argparse this could be an option (to remove hard-coded /etc):

The language settings of Windows have strange influence on Kleopatra and GnuPG.

Werner said we leave it as is for vsd3.3.3 and only change reading order of the configs for the change to the next mayor release.
So I make a child ticket for updating the documentation and retag this ticket for gpd5x.

Fixed.

Pushed the revised change to master.

I'm fixing this in Kleopatra similarly to gpg-card.

That's a good question. Looking at https://datatracker.ietf.org/doc/draft-koch-librepgp/, it doesn't really specify what encoding is used for "human-readable" notation, so I'd personally lean towards encoding it to stay on the safe side. Unless I'm mistaken, status-fd will only be used locally, so escaping overhead should not be a problem.

Will be in 2.5.14 but I am not yet sure whether or when we put support into gpgme

There will be a new "pfc" record to emit the used preferences after a "uid" record. --list-options show-pref must be given.

VS-Desktop-3.3.90.31-Beta shows no warning any more for the export of a newly generated key.

For argparse we use /etc as a default but applications may use gpgrt_set_confdir to set a different one. Howeever if we already have a new get_sysconfdir function, it is easy and useful to change the default on Unix.

In GnuPG we use CSIDL_COMMON_APPDATA and append "\GNU\etc\gnupg". If this can't be found we use the rootdir, that is he installation directory of the binary or one up if installed below a bin directory. The reason for using GNU and not POSIX or Unix is merely to avoid name clashes with other software ported to Windows. There was no real standard for this on Windows.

We already did this for Libgcrypt 1.8 but take care that an installer includig Libgcrypt should run something like

The question is who shall correct the wrong encoding of notation data (assuming it is flagged as human readable). Escaping is a solution but needs a lot of extra bytes.

It is not an ADSK issue. The problem is that the new subkey has not been entered into the fingerprint table and can thus not be found.

So this means, the order in the description should be implemented, right?