Note: The is a bug in the gnupg-w32-2.5.3 tarballs. After untaring cd to the directory as usual but then do:

rm PLAY/src/zlib/*.[oa] PLAY/src/bzip2/*.[oa]

before you run

make -f build-aux/speedo.mk this-native

2.2 is end-of-life.
There was one actual typo fix which could be used for master, though. Thanks.

Got a simple fix for this which does two things:

1. Correctly act upon an error from the backup file writing
2. Print a warning note.

There is a regression due to the regression fix in rGb30c15bf7c5336c4abb1f9dcd974cd77ba6c61a7 (from Dec 24 2015) or some related commits:

@gniibe: Please see gpgme/src/posix-io.c where we have this:

Check out the GTK version which scans /proc for the process to find the command line. Very handy for ssh sessions.

Note that that Beta uses a 64 bit Kleopatra but the GnuPG engine was accidentally build for 32 bit. This will be fixed with the next Beta. That might increase the confusion a bit.

All applied.

it would be best to add an API to gpgrt to iterate over registry entries.

But keep https://www.cs.auckland.ac.nz/~pgut001/pubs/heffalump_crypto.pdf in mind ;-)

That is what I expected. Meanwhile I re-read the code and history and can tell that the comment is not correct. I wrote it with PQC security level in mind which requires AES256 for the session key as well. However, during the migration phase and as long as --require-pqc-encryption is not enable we should allow an AES-128 session key. This is for the rare case that encryption is also done for non pqc keys which don't have the AES-256 capability set.

At gnupg/g10/pubkey-enc.c you will find

@ikloecker: Do you still have the private key for tests/json/key-with-revokers.asc somewhere? We need to remove the expiration date due to T7471.

Actually I would like to remove the option to install gpg4win at non-standard places because this is somewhat troublesome. However some users rely on this and thus we better don't remove i.

gpg: [stdin]: clear-sign failed: No pinentrysrc/libwinpty/winpty.cc, line 924

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

I can replicate this. A quick strace with LC_MESSAGES=de_DE shows (gnupg master)

show English or Turkish strings?

Jan, you please run something like

I am sorry, that I can't give it a high priority. See the discussion on the mailing list. I'll try my best, though.

@uwi: We removed the ciphersuite from the server and tested with 4.2.0 that you get an update notification now. Because of some caching you may need to

This is due to an update of the server providing the version info. The server (Apache) uses a smaller hash than the ECC key. This is allowed behaviour and was fixed in our TLS library in 2022; see T6059. However, the new library was released only early this year an. We will check whether we can tell our Apache to use a more correct hash algorithm.

What do you thing of storing the last WSAGetLAstError value also in the context and extend assuan_sock_get_flag to return this error value? The thing here is that I fear the mapped information is not enough to find the problem with the bind call.

Right, the first process is the gpg-connect-agent (via gpgconf). I used gpg just as an example. All processes use the same code to launch the agent.

Thinking again about this my hypothesis is:

In T7434#195318, @ikloecker wrote:

I'm wondering what happened (or why nothing happened) between the exit of gpg-agent[2816] at 10:11:12 and the start of gpg-agent[6492] at 10:12:00.