just checking in about getting this patch reviewed

I think what I saw and reproduced (and now fixed) was a different issue though. 5fd467a00d3ffa6c1ca83e9a248f4c01d77bbe72 broke IMAP connections for GpgOL in general. So we definitely will make a new, at least minor GnuPG VS-Desktop release. But first we need to reproduce and also fix your issue.

Good news is that I can reproduce the bug in our testlab by connecting an account via IMAP to exchange. Our other IMAP tests have intermediates like dovecot. The fix for this will be fairly simple but first I wanted to ensure that we could reproduce it for future testing of releases as this is a case that should have been covered.

Hello,
many thanks for the detailed report, I have given it some time to analyze and think I understand it:

@ikloecker Thank you for the pointer.
When people will use C23 compiler, there will be no problem (even with non-fixed version). That's good. :-)

I hacked configure.ac of gnupg to force it build with libgpg-error 1.45, and OpenSSH works with the created pipe. Maybe the libgpg-error fix is only necessary in some certain circumstances?

E:\key>gpgconf --list-dirs
sysconfdir:C%3a\Documents and Settings\All Users\Application Data\GNU\etc\gnupg
bindir:C%3a\Program Files\gnupg\bin
libexecdir:C%3a\Program Files\gnupg\bin
libdir:C%3a\Program Files\gnupg\lib\gnupg
datadir:C%3a\Program Files\gnupg\share\gnupg
localedir:C%3a\Program Files\gnupg\share\locale
socketdir:E%3a\key
dirmngr-socket:E%3a\key\S.dirmngr
agent-ssh-socket:E%3a\key\S.gpg-agent.ssh
agent-extra-socket:E%3a\key\S.gpg-agent.extra
agent-browser-socket:E%3a\key\S.gpg-agent.browser
agent-socket:E%3a\key\S.gpg-agent
homedir:E%3a\key

The "sysconfdir" "C:\Documents and Settings\All Users\Application Data\GNU" does not exist actually. Does it matter?

Looks like libksba 1.6.1 is available for download at: https://gnupg.org/download/ , however tag is missing at: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libksba.git;a=summary

Finally had some time to look into this a bit more.

A better solution could always be found later

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).