In T6272#165067, @werner wrote:

Actually I am not sure whether this is really a bug and that the fix is needed. What has been signed and verified is what gpg has seen and what --output has written. For example a line in the cleartext format may read "- From my " but what actually has been signed was "From my". If a line has been truncated --output will write only the truncated and thus verified data and not what was in the cleartext format.

Closing in favor of D556.

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

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.]

I will try, but it will likely be a while. In any case I believe you will need a Red Hat-family distro to trigger the bug; it happens when gpg trys to encrypt with a key that uses a public key algorithm libgcrypt does not support.

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

Reopening as gpg’s handling of the situation is very much suboptimal.

Closing as I believe this is a downstream bug.

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

Added missing context lines and replaced some tabs with spaces

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

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.

gpg-agent --supervised being deprecated is highly surprising, especially because it works so well with systemd.

In T5975#158113, @werner wrote:

I can imagine thar there are use cases for this. Thus I see no problems for the first part.

The second part is imho not a good idea. Libgcrypt is a building block for all kind of software and there are for sure legitimate reasons to use rsa512 (MCUs, short living keys, etc). Thus I think that the decision on the key size should be done by the software using libgcrypt.

I would be okay with GnuPG ignoring such packets, but I do not want verifying a signature or importing a key to activate the decompression code and its associated attack surface.

In T5993#158500, @werner wrote:

This specificiation is a draft which has not even been discussed in the WG. In any case gpg won't implement this because it would break processing of existing data.