This has been fixed in master with rG48978ccb4e:

Finally removed with gpgme 2.0

Closed after the release of 2.5.4

Right when you use a different homedir you also need to pass --homedir to gpgconf or set GNUPGHOME before invoking gpgconf. If you call gpgconf via GPGME the --homedir option is passed; afaics we don't have a kill option gpgme.

This even happens with native Windows applications thus normal priority. Users need to watch the taskbar for blinking items.

The caching works on the base of the requested domain, that is example.org and not openpgpkey.example.org - thus it should not make a difference when you change your setup. There is an initial test for a cached domain status before the resolving process starts. If you want to look yourself: gnupg/dirmngr/server.c:cmd_wkd_get() and domainfo.c.

Well, the different outcome depends on the order of the certificates or the string comparision in keyboxd. So it is not a keyboxd vs. pubring.kbx thing.

Okay, I can reproduce it when not using keyboxd.

I can't remember that we ever had support this. It is also not easy to come up with the good way to present the status for all files in a folder. We would need to define a format similar to what sha1sum uses: A list of file with they signature file or so. Note that kleopatra has support for running sha256sum in such a way.

Sorry. I can't reproduce this. Neither with master nor with the 2.4 repo version.

Can now be tested after the release of libassuan 3.0.2 (T6163)

Released with libassuan 3.0.2 (T7163)

Here we go:

Thanks.

Where do you find a statement that --keyring is deprecated? I planned to to remove it with 2.1 but there were too many requests to keep it and live with the problems of multiple keyrings. Thus the option stayed, it is just so that in addition to pubring.gpg and pubring.gpg we now also have the option for keyboxd - which is the default for new installations.

FWIW, for gpd and vsd we should use a different icon (blue head for gpd and red head for vsd)

Alright, my above putenv option won't work because it modifies the session environment and thus needs to be run for each gpg-agent session (connection). Adding a putenv_startrup option would help here but this way each connection could chnage the environment - also not good. In the end a way to modify the used environment variables, as you suggested, is a better way.

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.

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.

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?