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:

Mostly 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)

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.

Urgs

I pushed the longlong patch: rCb61a7661d017: mpi: Provide the function prototype of __udiv_qrnnd.

The card returned these 32 bytes:

1883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286

agent_card_pkdecrypt however returned 33 bytes:

411883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286

Thus the indicator byte is 0x41. The specs (librepgp, rfc4880bis) say:

We have now improved error messages, and this, combined with what could be considered a setup issue, I think we can consider this done for now.

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

IIUC, it's actually binutils version dependency (instead of GCC 15), perhaps.

I tested Ubuntu's version of GCC-15 (powerpc64le cross-compiler) and did not see this build failure:

In T7721#203182, @gniibe wrote:

For PowerISA 3.00 Instructions issue, following patch may help:

diff --git a/configure.ac b/configure.ac
index 6cc1e189..70d632af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2448,10 +2448,11 @@ AC_CACHE_CHECK([whether GCC inline assembler supports PowerISA 3.00 instructions
         else
           gcry_cv_gcc_inline_asm_ppc_arch_3_00=no
           AC_LINK_IFELSE([AC_LANG_PROGRAM(
-          [[__asm__(".text\n\t"
+          [[__asm__(".machine        \"any\"\n"
+                    ".text\n\t"
                     ".globl testfn;\n"
                     "testfn:\n"
-                    "stxvb16x %r1,%v12,%v30;\n"
+                    "stxvb16x 47,0,9;\n"
                   );
             void testfn(void);
             ]], [ testfn(); ])],

I figured out that .machine "any" is needed with GCC 15.

I figured out that .machine "any" is needed with GCC 15.

For Alpha (hppa, and sparc), IIUC, following patch may help:

For PowerISA 3.00 Instructions issue, following patch may help:

In short: A message was saved as an encrypted draft and then the user edited that draft, disabled encryption and then the message was sent out only encrypted to the draft key.

We won't implement that any time soon given that gpgol2 will be an easier plaform to get it right.

Thanks. Will go into 2.4.9 to be released soon.