In libgpg-error, I pushed thread-safe version : rE0313b660f8bd: w32: Don't convert slash->backslash when it's under Wine.
I'm going to push similar code to gnupg master.

Hi, I've managed to reproduce this bug on the gpg4win-5 beta as well. I think the frequency has gone down, perhaps, but it is still present.

The problem here is that iobuf_readbyte returns -1 on error and on EOF. parse_packet is not able to distinguish that because for histroic reasons we do not return a gpg-error code (GPG_ERR_EOF). To fix this we need to change all callers of parse_packet to not act upon -1 but only on an error code.

The latter is also the case for deleted softkeys.

Fixed in 1.56.

Fixed in 1.3.2.

We recently noticed problem at a customer site with creating the standard rsa3072 keys. It basically stopped working. A likely cause for this seems to be some anti-malware software slowing down file system calls. In the wake of this we looked again at our file locking strategy and found a few things which are not as they should be. For example the release of the lock before a Close call. Trying to fix this unfortunately caused other problems, thus a couple of fixes are needed.

I updated the branch.

I implemented that in the old 2.2 branch for easier testing.

Please let us not clutter the code with OS specific things. We could use a gnupg_remove_ext or gnupg_remove_maybe_wait with a wait parameter which maps to a plain gnupg_remove for Unix. The GPGRT_PROCESS_DETACHED, in the asshelp is also the only specific thing which can be move to a file global macro.

I think that modifying gnupg_remove is a bit risky because it's used in many places.
I'd rather introduce new function for Windows; gnupg_w32_delete_file for this particular purpose.
Factoring out wait_when_sharing_violation function from gnupg_rename_file.

Tested a little late and on Windows 11 with VS-Desktop-3.3.90.16-Beta (a Beta for VSD 3.3.3):

The gnupg_remove should retry if it has a sharing violation. Similar to what we do in gnupg_rename_file. I just figured that we do a remove in the latter function too w/o handling a sharing violation.

Here is a possible fix:

Tested with VS-Desktop-3.3.90.12-Beta

I can't find any causes of slowness in keyboxd initialization. I think that there is a situation where it simply takes time on Windows.

As there has been no more feedback on this for years, I'll close this.

2.2 test can be done with GnuPG-VS-Desktop-3.3.90.12-Beta-Standard.msi from Sep 17

Looks good to me on vsd-3.3.3-beta90.12 @ win10 (temporary filename is now attachment.odt or e.g. attachment (002).odt)

Interesting. That means to replace hundreds of scripts in an average organization :-(.

@ametzler1 Thank you.

Some data points:
The latest version of the standard (issue 8) has "The -a and -o binary primaries and the '(' and ')' operators have been removed." instead of "obsoleted" https://pubs.opengroup.org/onlinepubs/9799919799/utilities/test.html

Current logs for a forever hang:

still reproducible on gpg4win-5.0.0-beta369 @ win10

test -a is not a POSIX construct, I intentionally avoided it.

Thanks for fixing this.

@ametzler1 Thank you for your report.
I modified a bit (not using && between two test but using -a for a single test command), and pushed the change:
rP121494245f49: build: Allow build with fltk 1.4.

Since GnuPG 2.5.3 there is no predefined keyserver anymore: https://dev.gnupg.org/T7442

I believe this was fixed with Andre's commit above.

As this ticket is old, the original reporter never answered Andres questions and the second case seemed to be POP3 related, which we do not support any more, I'll close this.

Backported to 2.2 but not yes tested with 2.2

There was

Your first two issues are no issues. This is just usual output from a configure run.

Sorry, I just found out, that windows caps the filename earlier than max length, so my former tests were invalid.

Looks good to me on gpg4win-5.0.0-beta369 @ win10:

Is that really the same bug? I would be interested in seeing a more detailed report. BTW, Windows or Linux? Used standard beta installer on Windows?

If this is indeed a bug it won't be fixed in gpg4win 4. Thus a test with gpg4win 5 beta is highly appreciated. It would also be interesting to see what what version of gpg comes with Git.

How to test this? The follwing happens for an attachment of an encrypted mail on gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10:

In contrast to gnupg22 master did not proper show OCB compliance - not everything has yet been forward ported. But we can do so now and test master by setting GNUPG_ASSUME_COMPLIANCE=de-vs

@gniibe: Now that we use the KEM API, how do we proceed with this ticket?

Thank you for the report.

I don't see the problem. The pattern "Kyber768" is ambiguous because it matches the user IDs of both keys. The match is a simple substring match. There's no logic for "exact match" and no heuristic for "better match". If you want to ensure that a specific key is chosen then you must use a unique identifier for the key. Best use the fingerprint.

Backported for VSD 3.4

I see from your other report that you are running a proper libgcrypt. But I think I spotted the bug: ECC+Kyber should not be displayed when adding a key. It is used for creating a new key ECC as primary and Kyber as subkey.

Can you please try with gpg4win-5 beta: https://www.gpg4win.org/version5.html this makes it easier for us to see the reason. Deinstall gpg4win first and note that version5 is 64 bit and installed under Program Files (w/o (x86)). If it still does not work please add

Please run gpgconf -V to which tells also the Libgcrypt version and more.