Based on GCC bugzilla, affected released GCC versions are 11.1 and 11.2.

(ab | ba) >= 0 is used to make optimization analysis for compiler more difficult. I see that with (ab | ba) == 0, it would be much easier for compiler to conclude than loop could exit early as soon as first a[i] != b[i] is seen.

I filed a bug report to GCC, with modified test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102151

gpg verifies the content of the file and not its meta data (file name). Thus an empty file is identical to a non-existing file. The OpenPGP protocol does not allow to distinguish between a detached signature and an embedded signature if you sign an empty file.

I think this behaviour has something to do with "attached signature"?!

Aihhh, my fault. seems that a new version it not too far away.

The problem was created during a migration of the host operating system and acme client tools.

See description above.

Nah, I think I laid out all my arguments by now. I don't have more to add, so I'll just let it be.

Thanks for helping out @werner.

We will look into it but nevertheless I have to remark that this this portable thing is dangerous to use and you should avoid it.

Not at all. But 2.1 was such a large change that users really should have read the announcement and think about their use case. We have exensivly communicated the changes and can expect that users test their new installation. IF you have further comments, please use the mailing list.

You can write your own pinentry script instead of the loopback thing. The use the envvar PINENTRY-USER_DATA to communicate with the pinentry.

The same problem. Portable mode is completely broken in v2.3.2 and v2.2.30 on Windows.

I'm still sad that you don't acknowledge the problem I am describing. It seems that you are writing your software for the kind of user who reads all your documentation first. That kind of user does not exist.

Hello Mr. Koch,

The option has been removed form the repo more than 11 years ago and the gnupg with this changes (2.1.0) was released 7 years ago including an extensive writeup on all the major changes including notices that the secret keys will be converted and moved.

I wonder about the spelling errors. For particular

Please show us the output of

Fixed for (1): Now it writes correct record with valid checksum and flag.

Just for the record, Kleopatra and Gpg4win work totally fine for me on Windows-11 preview.

Code for avoiding the COMMON section has been there, because of RISC OS.
I think that it will be easier to enable that for all (but not for RISC OS only).

by the way when the applet is selected, I return
D2760001240103045343000000010000
this can be used to detect the manufacturer number

Card ATR at the cool reset
Card ATR is : 3B 9C 95 81 01 50 53 43 50 2D 53 43 53 56 31 2E 30 8E
Historical Byte is 53435356312E30
CARD ATS-to-ATR is : 3B 8C 80 01 50 53 43 50 2D 53 43 53 56 31 2E 30 0A
CARD ATS is : 11 78 80 B8 02 50 53 43 50 2D 53 43 53 56 31 2E 30
Historical Byte is 53435356312E30
This can by detected for the card type.

Is there another way to to detect your card (I assume a Javacard) without relying on the openpgp card application vendor-id like we do it with the Yubikey? I want to avoid a possible early but expensive AID selection just to get the vendor-id.

It is quite likeley that things don't work on a non-released Windows version. We have not tested with the released version but some of us already tried Windows-11 and the gog4win development versions do work. Please wait for the next Gpg4win version or an update of the Windows-11 preview.

Im using Windows 11
Before the restore, he are working fine
Im trying to sign a file
The kleopatra dont show more error info

Package maintainer from PLD here. We still ship Qt4 and therefore provide pinentry qt4 for as long as it's supported. I have no problem with dropping it if it's no longer support, but last release still supported Qt4, there's no mention of dropping such support in NEWS and both code as well as configure.ac appear to still carry Qt4 support which is a bit confusing.