This is a support question and not a bug. You should ask such questions on the channels for Gpg4win, which does the Community support for GnuPG on Windows: https://www.gpg4win.org/community.html

I would give this low priority as we default to "S/MIME disabled" and this issue is no longer that relevant. But as it is a regression and I am pretty sure I know why it happens -> Normal.

I think it is more of a Kleopatra issue.

Yes I have to look at this again. This resize stuff is code in GpgOL, which was intended to trigger UI redraws / updates of Outlook. Because it otherwise would not show our current state but something in the cache. And there is no "Redraw UI" Api. The Resize trick is something I got from stack overflow but it should be only 20px (seriously smaller px values cause no redraw) But there is a bug here when it is maximized I think.

Another thing we noticed today is that the pgpOnly check that determines if S/MIME and PGP or only PGP is shown (The radio buttons at the top right corner) is done only at initialization. So if you import your first S/MIME certs it will still only offer PGP certs and no option to switch. Just as a note here instead of a different issue because it is mostly for testing but should be improved on an update.

works

Well, the picture given as example above looks exactly as before if I choose a key by clicking on it. But at least it changes after hitting return or switching to the next line, so it's an improvement.

I see no change in the reported behavior:

Ok. Let us resolve this. The patch is in kconfigwidgets without a version marker and I already added a patch-next next to it for future versions of kconfigwidgets. Should be no problem to keep.

That's from my confusion. I'll revert.

No, it does not matter.

Sorry, you need to wait for gnupg 2.3.8. It's next on our shortlist.

Testing gpg-auth : There are two different use cases

• test with xsecurelock for screen lock
• test with pam-autoproto for login / gdm / etc.

Why? One underscrore followed by a lowercase letter is not a reserved symbol. It is common to use this for symbols which are not part of the public API but need to have global linkage. Also not all system have a way to limit the visibility and there we need to use them for internal symbols.

Here are pam_authproto.c with Makefile, so that you can compile it with libpam:

If you could try: https://files.gpg4win.org/Beta/gpgol/2.5.5-beta2/x64/ (Source tarball in the directory above, signed by my key)
If you could enable data debugging though (Include Data) in a log. And send it to me

What is a partial CRL; I have never seen that and IIRC the specification for that was not complete.

We want to get rid of sshcontrol but we could keep it as an optional configuration to sort keys. I won't say it is a bug, though.

For what it is worth, I think that my patch is more standard compliant then yours because it checks if there is a partial CRL.

I think 289fbc550d18a7f9b26c794a2409ba820811f6b3 implemented this wish from 2016 :) @werner please read the full report and then close it as fixed if you agree. I find it a bit funny that we both came independently to the same conclusion, that it should be handled differently even if the standard says otherwise. Because the behavior from the standard does not make sense and is in contradiction to other parts where it says that each CRL must contain all revocations.

If you could try: https://files.gpg4win.org/Beta/gpgol/2.5.5-beta2/x64/ (Source tarball in the directory above, signed by my key) Doc for this can be found here: https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

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.