In T6209#163363, @werner wrote:

Also the use of the standard-resolver is not a good idea because it does not work with Tor.

The use of

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.

Here some further investigations ...

I suspect that this has to do with your usage of tor (or gpg thinking that you use tor) because in dirmngr/dns-stuff.c I found

if (tor_mode)
  return gpg_error (GPG_ERR_NOT_ENABLED);

and all other places returning GPG_ERR_NOT_ENABLED seem to be related to S/MIME.

Lookup on server should no longer report any errors caused by a failed WKD lookup.

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

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

In T6205#163303, @ikloecker wrote:

Does the recipient know the public key that was used for encryption?

Does the recipient know the public key that was used for encryption?

Actually, noreturn isn't a keyword. The keyword is _Noreturn. noreturn is a convenience macro, which is provided in the header stdnoreturn.h. Funny enough, _Noreturn and the macro noreturn will be deprecated with C23 in favor of the new attribute [[noreturn]]. :-)
https://en.cppreference.com/w/c/language/_Noreturn

The data from the above output was additionally OpenPGP encrypted to self.
The "not compliant" message only shows when the data is additionally encrypted to a public key.

gpg: Öffentlicher Schlüssel ist 2B2F1C74FE523D81
[GNUPG:] ENC_TO 2B2F1C74FE523D81 1 0
gpg: AES256.CFB verschlüsselter Sitzungsschlüssel
[GNUPG:] NEED_PASSPHRASE_SYM 9 3 8
gpg: Verschlüsselt mit einem Passwort
gpg: verschlüsselt mit RSA Schlüssel, ID 2B2F1C74FE523D81
[GNUPG:] NO_SECKEY 2B2F1C74FE523D81
[GNUPG:] BEGIN_DECRYPTION
gpg: AES256 verschlüsselte Daten
[GNUPG:] DECRYPTION_INFO 2 9 0
gpg: Ursprünglicher Dateiname=''
[GNUPG:] PLAINTEXT 62 1663253724
[GNUPG:] PLAINTEXT_LENGTH 4
test[GNUPG:] NEWSIG
gpg: Signatur vom 15.09.2022 16:55:24 Mitteleuropäische Sommerzeit
gpg: mittels RSA-Schlüssel 930A7B212C8EC8F1729DA3F5C464074875570823
[GNUPG:] ERRSIG C464074875570823 1 10 00 1663253724 9 930A7B212C8EC8F1729DA3F5C464074875570823
[GNUPG:] NO_PUBKEY C464074875570823
gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel
[GNUPG:] DECRYPTION_OKAY
[GNUPG:] GOODMDC
[GNUPG:] END_DECRYPTION

Pushed similar changes for GnuPG and libgcrypt (which are actually harmless as it is internal use, not exposed header).

To clarify that I meant that the underlying problem is our current keylisting speed in Kleopatra I have opened T6206.

Here is another Test:

In T6195#163175, @werner wrote:

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.

I agree with that task. Errors should be logged but not exposed to the user. I like the decryption / verification audit log we have now for some years (quite new) which allows users to view the stderr of gpgme jobs. Something like that -> Perfect. I think we need this for Import also and basically for every job. If you had an idea, maybe in the status bar or so, to indicate that more error information would be available. That would be my dream solution.

Just for your understanding, it this output would say "COMPLIANCE 23" anywhere in it, Ingo and me should look at this issue, if it does not that is something for Werner or Gniibe.

Could you please post the output of 'gpg --status-fd 1 --verbose --decrypt "Neues Textdokument.txt.gpg"' here? That would help us to pinpoint the issue.

No, I was just meaning that you should not have to disarm your logs when include data is not set.

Should i create a new log without "include data" ?

Yeah the error would lie in here I think:

I do not have a mind to really analyze this today, but when the checkbox in the logging options for "include data" is not set. There should be no much as an IP Address or Fingerprint mentioned in the logs. This was important to me and if you find that there are issues with that it would be a different bug also.

We have tested this a lot of course. But I will have to analyze your logs. Thanks.

In T6111#160993, @ikloecker wrote:

Please give this a try on Windows.

:)

On Windows, it does now look like this:

The Certify action is now disabled everywhere for revoked and expired keys, i.e. in the main menu and the certificate list context menu, in the Certficate Details dialog, and in the Certifications dialog. Moreover, after importing a revoked or expired public OpenPGP key, the user isn't asked anymore whether they want to certify it.

Pushed the fix.
Note that non-in-tree build never been reliable (using the result of the configure, in tree).
So, I basically don't consider the use case of non-in-tree build.

Reviewing the build process, it's just better to use @...VAR...@ by configure (instead of invoke pkg-config again in setup.py).

Awesome, thanks all! From an end user perspective that would be a perfectly acceptable outcome, the warning just serves to confuse people. Appreciate the help!

I have created the spin-off T6202: Kleopatra: Suppress errors of WKD lookups to deal with not bothering Kleopatra's users with error messages when doing a WKD lookup in the background. This task is for improving dirmngr.

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.

works now