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.

This is addressed in my blog post; I set the GPG executable used by Git in the configuration so that it uses the one shipped with Gpg4win:

Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10
(tested with 10 restarts)

Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10

The problem is likely the gpg which comes with Git on Windows. Depending on where they are in the %PATH% a wrong one will be used. Please run gpgconf -L to check that the correct version of gnupg is used. I have never used git on Window but I would suggest to remove the gnupg binaries which come with Git and adjust the gpg.exe name in the global config.

It's in master (to be 1.12), then, it's backported to 1.11.2, which is confirmed build well.
So, closing.

Thanks for testing.

Hello,
thank you all. I can confirm that 1.11.2 builds successfully on ppc64el with gcc-15 (Debian sid + experimental). Lacking access I have not be able to check alpha. I would suggest closing this report as fixed.
cu Andreas

OK on Linux now with new enough versions (Fedora 42).

Finally came around to check this.
On Fedora with Kleopatra 25.04.03, gpg 2.4.5 and pinentry 1.3.1 the pinentry window ist above the Kleoaptra windows.

Looks good to me on gpg4win-5.0.0-beta357 @ win10

Pushed the changes in {gniibe/synch-spawn} branch.
It consists of three commits:

• rGb8b8afc5cf6f: build: Require libgpg-error 1.56 or newer.
• rG15b8bc7495db: w32: Synchronous spawning gpg-agent/dirmngr/keyboxd.
• rG6bd6826aa6ff: common:w32: Care about the NUL device for start_new_service.

Ok, thanks. I pushed the powerpc patches to master.

tested with Gpg4win-5.0.0-beta357 (GnuPG 2.5.11):

I can confirm that the crash is fixed by the change.