Fixed by https://dev.gnupg.org/rGPGPASS7587429ed4da7b5002cdbb35c4d1e7e649c2bac5

(ignore the last commit, I assigned the wrong task to it)

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.

Ok. Sorry, just to avoid debugging in case it is not known, I am pretty sure the ini file is a regression from the unicode nsis switich. The timing when it was reported to no longer work matches around that time and the installer code itself hasnt changed for even longer.

In T7452#195845, @aheinecke wrote:

I doubt it as what Gpg4win does here is completely standard. So the win_package module should handle it or there would be multiple results if you search for "NSIS uninstall ansible"

In T7454#195889, @ikloecker wrote:

Which dialogs? pinentry? If yes, then your assumption is correct. pinentry also gets the texts from GnuPG.

Which dialogs? pinentry? If yes, then your assumption is correct. pinentry also gets the texts from GnuPG.

I'm not sure what we need for the clipboard that's not already in the SignEncryptWidget. I think the SignEncryptFilesDialog mostly adds functionality for the file handling. It might make more sense to try to share code that's implemented for the Notepad and then wrap this in a simple dialog.

There is another customer request for this too.

Thanks for the clarification, it seems that was necessary.

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.

There were three parties involved:

• gpgconf --launch gpg-agent
• gpg -k ...
• gpgsm --server followed by LISTKEYS command

Just a note (in case it was not clear enough): I was *not* talking about registering "*.pub" for Kleopatra (currently it launches Microsoft Publisher), but I was talking about the file selector's default input pattern (I had to switch to "all files" to be able to see the file I wanted to import):

Thinking again about this my hypothesis is:

IIUC, simpler solution would be modifying m4/socklen.m4 adding Solaris variant specific code.
Tweaking _XOPEN_SOURCE requires the change of Autoconf (if done correctly), which would be larger surgery.

Here are changes for gcry_md_open and its friends.

My idea in https://dev.gnupg.org/T7338#195529 doesn't work well when a function call is done multiple times.
Assuming SUCCESS, and marking all non-compliant places in the code works, and it would be good because libgcrypt so far maintains non-compliant path with rejection.

In T7452#195841, @m.eik wrote:

this could also help with T5952, i was testing with ansible as well.

- name: Uninstall gpg4win from the registry
  ansible.windows.win_package:
    product_id: 'Gpg4win'
    arguments: /S
    state: absent

From a quick glance at the docs. This looks completely correct. What did this do and what didn't it do?

In T7452#195836, @aheinecke wrote:

To workaround you need to copy the uninstaller to a temporary locationm firs and then execute and delete the copy.

Backported the latest change for VSD 3.3

Just to explain, if you are executing it from the command line the command line will "lock" the uninstaller until it is finished. In GUI Mode it creates a copy in %TEMP% launches this copy and exits. When run from the command line it requires a session reset to delete the unistaller. So log out / log in and the uninstaller should be removed, but the dir might still exist. I am not sure. To workaround you need to copy the uninstaller to a temporary locationm firs and then execute and delete the copy.

I wasnt aware of this either, but it would be good since we currently don't have a file extension listed explicitly for pgp keys, even though we register one and have the strings already to handle downloading keys where the server transfers application/pgp-keys as information. While https://support.microsoft.com/en-us/windows/common-file-name-extensions-in-windows-da4a4430-8e76-89c5-59f7-1cdbbc75cb01 recognizes it as Microsoft Publisher file wikipedia says PGP Public key but without a citation. If AllowSilentDefaultTakeover is not set, the following code will not automatically change .pub to kleopatra. Instead in microsoft publisher is installed, it will ask you for the first time when a .pub file is opened after installing Kleopatra if you want to keep opening the files with Microsoft Publisher or if they should be opened from now on with IKleopatra,.

I misunderstood the problem. On the receiving side this was already fixed by me in 2019 9a9fe4e7fcad92bfba49ade9a6c44373f170ccd2

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.

Also fixed for 2.4. Don't use the uninstaller on the command line, you should use the Windows method to do this.

Fixed with rG4c830b240c for gpd5 but after the release. Will fix it for 2.4 too.

Really. I do this for PGP files but I have not seen that elsewhere.

There is consensus that the issue T7434 must be resolved in the backend, where it originates.

There is consensus that the issue T7434 must be resolved in the backend, where it originates.