I just fixed a bug related to the DP. That might be related. See rG0c8299e2b56ef2e1

That particular bug seems to have been solved a long time ago. I stumbled upon up while fixing a DP bug today.

What is the output of gpgconf --list-dirs ?

Works as designed. Whether the design is a good choice is a different
question.

keyboxd has nothing to do with this, it merely makes the lookup of keys a bit faster. The computation of the WoT itself takes long and there is no shortcut for it. Fortunately most users don't have a deeply meshed WoT with dedicated revokers etc., thus for them things are fast in the standard configuration.

If you run gpg --export-ownertrust you will notice that the trust has been set to ultimate (value is 6). However, due to the no-auto-check-trustdb in your gpg.conf that will valeu will only be shown after running gpg --check-trustdb. The value shown in the key listing is the computed value and the computation is done by --check-trustdb. I don't see a bug here.

I see what I can do

Of course it could be refined to use the same host if there is only a relative URL.

That's for sure. See rGfa1b1eaa4241ff3 :

Kleopatra does searches in parallel. What you see in the second dialog might be a response from a Web Key Directory (i.e. search by mail address with lookup at the mail domain).

BTW, gnupg/doc/DETAILS tells that the fingerprint is optional:

Fixed for 3 lists. I can't remember the details but quite some time ago someone requested some changes and while applying them the host_name must have changed / I changed it. The problem with Mailman is that it does not use plain config files to keep under etckeeper. At least not with some effort.

Thanks for mentioning this. I looked at the CVE last Sunday and figured that we are not affected. The vulnerable function inflateGetHeader is not used by GnuPG because we don;'t support the gzip format.

The more relavant error is that there is no status output on failure which is what gpgme uses (due to double forking).

gpgv returns success iff the signature is valid. That is the whole purpose of this tool.

Can you please give a more detailed example with regedit files to demonstrate that?

Can't we get them from the help.txt file? Putting a tooltip into the pattern file would be an option but needs substantial changes,

Yeah, we known. Fix is rGf34b9147eb3070b see T6070

Thanks for testing. I guess I will do a new release.

Standard behaviour for stdio functions.

For master (2.3) the fix is not needed due to another way the code works, but having a more robust function is always good.

You may try the above commit - if should apply cleanly to 2.2.37.

You are right. This due to your old binary private key (stubs). Otherwise you would at least have one item ("Key:"). I need to see what do do about the release. Maybe a tool to update the key files would we a good workaround.

Oh well, why do I receive such bug reports right after the next release :-(

Small correction: We don't have replicas of our code signing key. I mistook this with out Authenticode signing key.

In general I use my standard ed25519 signing token for all software. However, GnuPG VS-Desktop is signed using a Brainpool key named GnuPG.com (stored on a smartcard with 2 replicas) for the simple reason that it does not raise questions when ppl update their GnuPG VS-Desktop and run into a non-compliant key.

This looks like a different but not too uncommon problem. For T6169 we need to get a PKCS#12 file to be able to replicate the problems - obviously that PKCS#12 should hold only test keys/certs.

It turned out that this is pretty important if you use a current version of scute; That one uses gpg-connect-agent to list all smartcards. And gpg-connect-agent will start and take over a remote socket used for the card.

You get this error because the key has been created in gnupg mode (and not in de-vs) and thus it has these preferences.

Let's turn this into a feature request.

I think we can close this one. Note also that we now have --no-user-trustlist and --sys-trustlist-name. in 2.2.37 and 2.3.7 which allows to entirely ignore the user trustlist and to define a global one..

@dkg: Thanks for the detailed description of the problem.

I added this option on 2005-07-19 and iirc this was planned for the FSFE's rig to produce their membership cards. I kept that option in 2.0 for backward compatibility but it does not make any sense because its gpg-agent's duty to ask for cards - gpg does not known about it.