Somehow I was waiting for such a comment ;-) Sure you are right and we will fix the README eventually.

See T6310 and the release note update at T6303.

Sorry, I can't replicate this.

This bug is CVE-2022-47629

This does not look like a problem in GnuPG/gpg4win because gnupg implements the ssh-agent protocol and not the ssh server or client functionality. ssh tells sshd whether it shall allocate a PTY (Pseudo TTY). I don't use ssh with github but it is likely that you may only run commands (which don't require a PTY). Usually you would invoke a "git" command cia ssh.

I pushed a similar fix last week: rE885a287a57cf060b4c
and gnupg has a hack to fix it for oler libgpg-error versions.

I meant bypass the gpgme engine and call gpgsm directly. Maybe using gpgme's spawn engine. But I am not sure whether this is really a good idea. If we can find a way to pass multiple filenames to gpgsm --server that would be better. But requires updates to gpgsm.

With 100 concurrently running gpgsm processes they all try to get the lock for the keyring. And they need to do this several times and often also for the same certificate (fetched from an external resource to complete the chain). Not good. It might be easier to bypass the gpgsm and run gpgsm directly instead of adding a feature to gpgsm to directly import from many files.

Note that in-source-tree builds are broken - see T6313

Unfortunately this breaks in-source-tree builds - see T6313

You should do it for all software ;-).

You are building in the source tree - not a good idea. This should be supported but we don't test this. Please make your life easier and don't do build this way. We try to fix this for the next release.

Release done

To be released tomorrow.

@raysatiro: Please re-open if you are able to give us a reproducer

Fixed. Shall we backport this to gnupg22 ?

We sometimes grant our customers the privilege of receiving updates a few days earlier than the community. It is not really helpful if you publish that fact anyway on a public tracker. BTW, there is no community version gpg4win 3.1.26.

Fix for 2.4 is rG2aacd843ad

Thanks. Commited to master.

If you pass NULL to that function, the calling code is wrong. No need for an explicit check in nomralize - check should be done in the public API (if at all).

It seems that we removed the support for the BOM at some point in the past. Probably because config files are anyway suppossed to be utf-8 encoded.

Fixed by reverting to 2.5.5

Problem is that Kleopatra uses the latest libassuan from Git and not the released version. Replacing the libassuan DLL with the one from the gnupg directory fixes the bug.

The actual problem at hand is that the nonce is not correct. The UI-Server is actually started but if a client (or the self-test) connects the connection succeeded but then the server needs to check the nonce which does not match. Procmon shows that there is only one nonce writen - so the problem might be that the server has different copies of the nonce.