No, unfortunatelly problem is still existing.

Even if it is only a single case (of old version of Wine), I think that it is worth to add es_fflush when writing to file.

What about rejected changes to "Key:"?

Hat sich das Problem gelöst? Bei mir tritt das seit gestern auf auf. Ich kann nichts mehr signieren oder verschlüsseln. andere Plugins habe ich deaktiviert, es beliebt trotzdem.

Some issues with the dialog:

• The user id list is in the wrong tab order (just before the Close button).
• The certificate details are not (easily/separately) accessible for screen readers. (Idea: Use read-only line edits so that they can be assigned to the labels as buddies.)
• The user id table is not accessible at all (neither the whole rows nor the individual cells).

What about rejected changes to "Key:"? Other this command would make it too easy to mess up the actual private key.

In rC76aad97dd312: fips: Reject shorter key for HMAC in FIPS mode., I added rejection, but it would be good to move the check to src/visibility.c to allow internal use.

Looking illumos-gate, Solaris variants have no issues.

Wine 5.0.3 (on Debian bullseye) fails.
Wine 6.0.3 Debian testing does no failure.

This problem does not seem to exist in GnuPG 2.3.6.

My intention to refer rG7b1db7192 was to specify the HEAD of STABLE-BRANCH-2-2, meaning "the head of STABLE-BRANCH-2-2 today". The commit itself has no meaning.

I created minimized test:

Closing in favor of D556.

When failing due to a bad packet in a detached signature, log the
packet's type.

I fixed the title, because it is not a Windows only issue.

The mentioned "g10: Fix garbled status messages in NOTATION_DATA" has nothing to do with the problem. So it can'r be the actual cause. Anway, I hope to get a 2.2.36 out this week.

iirc, we use ftruncate for ages now. The problem with the name ftruncate is that it looks to similar to the stdio functions. But sure, things should be flushed first.

I can replicate the error by 2.2.35, but I cannot replicate it with rG7b1db7192.
I tested:

• GNU/Linux
  • i686
  • x86_64
• Windows
  • i686

Compressed packets in detached signatures and/or certificates have never been permitted by any version of the standard.

In D555#5569, @werner wrote:

Sorry, there is no padding packet in OpenPGP. Please do no try to push ideas from that crypto-refresh-06 thing into GnuPG. We continue to follow the last draft with consesus, which is rfc4880bis-10.

The likely cause is that the secret key is not protected. Problem seems to be in gpg-agent.

Looking again at your report, I don't think it is an IPC problem (bad magic cooky was my assumption). I can replicate this with the current 2.2 but not with 2.3. Both un Unix.