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.

Printing a note as we do in --edit-key is a good idea.

The reason for this is probably that we expect that several UIDs are added and running a check-trustdb for eachleads to some extra waiting time.

(Werner just told me that I was mistaken and he needs to take a look. There was a mixup because of the 2018 CVE number.)

Sorry, that was a misunderstanding. My fault.

In fact, decent 2.2 versions (>=2.2.21) have the ability to decrypt AEAD packets - this has been implemented exactly for the case that some things get wrong at the user site. But we can't change old versions - we are not the Sirius Computer Corporation. I close this ticket because we can can't do anything if you are not able/willing to update to the latest version of the respective branch. Sorry.

@werner
The setpref S9 S8 S7 S2 H10 H9 H8 H11 H2 Z2 Z3 Z1 worked!

S9, etc. are short-hand IDs, for the cipher algorithms, digest algorithms, etc. Use showpref instead of pref to get the preference list in human-readable form (AES256, SHA512, etc.) instead of in expert form (cryptic IDs).

Hi @werner
I had missed your earlier post quoted below on using setperf.

Create the keys with gpg 2.2. I'm not aware of such documentation apart from the manual page of GnuPG. And, as I tried to explain, this situation isn't really different from any other software. If you create a document with the newest version of LibreOffice then you cannot expect it to look exactly the same with an older version of LibreOffice. It's your responsibility not to use new features of the new LibreOffice if you still need to use an older version on another machine.

@ikloecker Thanks for the clarification (appreciated).

Backward compatibility means that newer versions work with data created with older versions of a program. What you are asking for is forward compatibility, i.e. you want older versions of a program to work with data created with newer versions of a program. In the extreme that would mean that gpg must not use modern encryption algorithms because old versions of gpg cannot deal with them. It should be obvious that this doesn't make any sense.

@ikloecker thanks for your reply.

Not in the way it is used by gpg. See T5880

Not in the way it is used by gpg. See T5880

Good idea. Thanks. Goes onto 2.3 and 2.2

In T5886#156407, @TonyBarganski wrote:

2. As things stand right now, someone with a Public key created on gpg version 2.3 on a macOS cannot privately communicate with someone using a Linux server, news group or Linux Desktop.

Use a gpg 2.3 version:

Hi Werner
.
Firstly, let me say how much I appreciate the work you and others do at OpenPG.org! Really.

• No we can't because current GnuPG 2.2 versions are able to decrypt such AEAD data.

1. So, firstly, can we get an error message that states something to that effect AND can also be displayed by Mutt?

Packet 20 is the new AEAD packet which GnuPG 2.3 can generate and does generate if all recipients have new keys generated with such a versions. However, the version of gpg you use now does not support AEAD and thus fails.

Using an armor header would allow for this. But well, this blows up the data and frankly, I fear that it can lead to unexpected side effects. Better to use a respective file name or MIME header.

Adding

GPG_TTY=$(tty)
export GPG_TTY

makes this working so thank you for the pointer.

Is your GPG_TTY set so that pinentry can find the right tty?

the -v does not show more useful info on the gpg side:

# gpg2 --quick-gen-key admin
About to create a key for:
    "admin"

Please run with option -v to see what's wrong with pinentry.