Fixed with commits
rGeb675fbc4e4db52c3276bc0748b49df8a213fbc4
rG890e616593af5d1e0f2eb932768205ef90928e5e

Yes, I think that makes sense in the way that we want to provide the best user experience for our own users even if they communicate with communication partners which creates problematic keys.

In de-vs mode we could change the implict algorithm from SHA-1 to SHA-256. That should solve the problem.

@werner Could these two patches could be backported to 2.2? These changes give same level of performance increase in 2.2 as seen in 2.3.

Fix will go into 2.2.37 and 2.3.8.

There won't be any semantic changes for obvious reasons.

@gniibe Thanks!

In the repo, for all related software, it's done.

Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.

Thank you.

It's in 2.3.7 and 2.2.36.

It's in 2.3.7.

In gnupg/common/ttyio.c, the function w32_write_console does:

• Call WriteConsoleW, and when it fails, it calls
• WriteConsoleA

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.