Yes, the workaround is to use a pinentry wrapper script that sets the value back to the correct one and then invokes the real pinentry.

Kleopatra with Breeze style:

Looks the same in VSD 3.3.0 ans in Gpg4win:

This is the current (VSD 3.3.0) state for Japanese (with German as fallback):

I'm not going to keep re-opening a ticket that you keep closing. So i'm just going to state here what i believe to be the upstream intent is. If you think this is wrong, i'd love a clarification. I believe that "deprecated" means that the GnuPG project believes that an option or configuration choice should not be used, and will eventually go away.

The actual cause here was that right before storing the imported key we need to decide whether to insert or update a keyblock. For this we need to lookup the key in our database and the lookup function does the usual thing by looking at any fingerprint. This is wrong: Here we need to lookup only by primary fingerprint. This is what the above patches do.

Everything mentioned above was translated and is now shown that way in all three languages.

I would keep the "create group", too.

In T7515#198012, @alexk wrote:

Regarding the suggest list I would change the following:
but keep:

• Enable/Disable Certificate

Regarding the suggest list I would change the following:

That is not a new issue. We have the very same issue since ever. However, without keyboxd you had random results depending on the order of the keys in the keyring.

That is an installation/migration question and the warning is just a convenience thing to remind the few early users of keyboxd to migrate to common.conf.

As usual use ./deadbeef.... as the filename to distinguish it from a fingerprint.

To be clear about what's going on here, blocker.cert has simply adopted the primary keys of each certificate found in /usr/share/gnupg/distsigkey.gpg -- i think GnuPG requires each component key in its keystore to have a unique fingerprint across all component keys in the keystore. so when one certificate claims those fingerprints as subkeys, any certificate that has a primary key with a matching fingerprint gets rejected with doesn't match our copy.

I understand you as saying you won't fix the fact that the warning is not emitted during initial homedir setup. I'm not sure why that scenario is not worthy of a warning when a post-setup scenario is, but okay.

thanks for correcting that, @ikloecker. i've corrected the initial report.

I did a quick test with a test user running a Wayland session and the AppImage works now.

What about deleting the environment variable in gpg-agent:

gpg-connect-agent 'OPTION putenv=DBUS_SESSION_BUS_ADDRESS' /bye

or to use a pinentry-wrapper?