ACK. P[ease add it also to 2.2.

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.

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.

I created minimized test:

Closing in favor of D556.

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.

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.

In T6031#159248, @werner wrote:

{please add comments instead of adding the description - a changed description makes it hard to understand follow up comments. I will change the title, though for clarity.]

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 length limit of the signature sub packets are not reasy to pre-compute. Better to have a fatal error than a corrupt message. I am not sure whether we want to change this to a regualar error message - at that point we anyway need to stop.

Reopening as it appears this issue was closed based on an incorrect understanding of what it is.

The original description of the problem seems to be wrong. gpg-agent does not have a KEYPARAM command. If I understand correctly then gpg-agent sends a KEYPARAM inquiry to the client, but you are sending KEYPARAM to the server.

FWIW, on Unix is common to describe options as given on the standard shell.

The quotes are irrelevant because they are evaluated by the shell and don't make a difference here.

No crash here

For clarification, the strings I have provided are raw argv elements as would be passed to execve(), with quoting already removed.

The quotes are irrelevant because they are evaluated by the shell and don't make a difference here. A Unix shell is different than Windows cmd.exe.

Please provide a more verbose report.

I am using GnuPG 2.3.4 on Fedora Linux. I am referring to --list-options=show-sig-subpackets="100"a (note the quotes). The bug is that the character after the trailing close quote is ignored, rather than being treated as an invalid option and causing an error. That is, I would expect show-sig-subpackets="100"a to be parsed as show-sig-subpackets="100",a or be an error.

Please explain what you mean by this. Which GnuPG version, which OS, which shell, what is the problem.

Added --enable-maintainer-mode to ./configure

Sorry, no. Use cat(1) for such translations.

Part 2 patch is pushed, with a bit of change.
A user needs to specify "Confirm" flag in the key file.

Part 1 patch is pushed.

That is expected. The export re-encrypts the secret parts to comply with the OpenPGP specs and this includes a salt andf IV and thus the output must be different.

To detect these kinds of bugs, possibly, we can use new GCC option: -ftrivial-auto-var-init=0xFEFEFEFE.
https://gcc.gnu.org/gcc-12/changes.html#uninitialized

The bug was there when it was initially written. It was in 2003, which introduced PC/SC in rG1bcf8ef9dea1: Cleanups, fixes and PC/SC support

We have everything ready for a GnuPG Desktop Appimage but we first need a business case to maintain it.

TL;DR: can reproduce, needs fixing

I examined all log files you gave us, and I think that scdaemon with PC/SC fails to detect the removal of the USB device.

I've applied the linked patch, but still experience the error. Most of the times, I cannot access my yubikey at all and I am not sure what is blocking it.
I've tried to include as much debugging output as I could below. Please let me know if there is anything else I can do to debug this.

The patch rG054d14887ef8: scd: Add workaround for ECC attribute on Yubikey. fixes a particular problem of Yubikey implementation where it returns bogus octet for its data object of C1, C2, and C3.

With the patch and after starting a new gpg-agent, gpg --card-status now works immediately.
But when I re-plug the yubikey, gpg reports gpg: OpenPGP card not available: Card error until either gpg-agent is restarted, or pcscd is restarted.
pcsc-lite in debug mode reports no errors, but one log is obviously much shorter as gpg fails early (I've attached both, same pcscd and gpg-agent instance).

I pushed a workaround.

For my environment, it is not PC/SC-specific. It also occurs when CCID driver is used.

For bcdDevice 5.24, I can replicate the symptom, but only once. After second invocation of gpg --card-status, it works well.

I've applied the patch and can confirm that the segfault is fixed, but gpg still has severe problems communicating with the Yubikey over pcsc-lite.

Ours are even newer (5.4.3). Did you the Yubico tools to switch to curve443?
In any case, is it possible that you apply my fix and test again?

Your Yubikey's firmware version is 5.2.7 - let me see what versions we have in stock to test my fix.

I've taken the liberty to regenerate the valgrind report including libc and gnupg debugsyms. Maybe it'll help.

I am not sure about the crash but the unknown curve is
1.3.6.1.4.1.11591.15.1.2 which seems to be a GNU OID for curve448

It segfaults on SERIALNO. Here's what valgrind outputs:

What I would do in this case is to stop the gnupg daemon amd anything whiuch might start them and run scdaemon under valgrind.

Works together with the changes for T5939: Kleopatra: Better error for wrong password in symmetric decryption. Tested with symmetric encrypted file and with symmetric+pk encrypted file.

Seems we can close this bug.