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?

I think at line 82 we should use xtrymalloc as always in gpg-agent. xtrymalloc expands to gcry_malloc.

That's what gpg-card url --clear does

if (!strcmp (argstr, "--clear"))
  url = xstrdup (" "); /* No real way to clear; set to space instead. */

Yes, by definition an immutable group doesn't allow any changes for that group. Don't mark a group as immutable if you want to allow changes.

Fixed in 2.5.13.

@onickolay The change was originally introduced for PQC stuff. And then, we applied use of KEM API (of libgcrypt) also for ordinary ECDH, so, it affected ordinary ECDH encryption (between 2.5.9 and 2.5.12).
The intention is follow the recommendation of use of KEM. IIUC, next FIPS certification will require use of KEM, possibly.

@gniibe @werner Is this change is supposed to work only for PQC stuff, or non-PQC as well, and where it is defined? As it breaks RNP tests for ordinary ECDH encryption (as it looks up for 0x40 prefix). It's not a problematic to update our code, but just want to know the reason for that.

The [KDE Action Restrictions][$i] in XDG_SYSTEM_DIRS/kleopatrarc prevents any changes within the whole group afterwards.
I guess, this is intended by defining an "immutable group", but i doubt that we want to prevent admins to change those settings?

So, regarding the minor version change: the change of order seems not critical (as there was no settings file before), but the introduction of the settings file might be.

I verified, that both in vsd 3.3.2 and vsd 3.3.3 beta90.29 the current implementation is