[pkg-gnupg-maint] Bug#1105820: Bug#1105820: Bug#1105820: Bug#1105820: Bug#1105820: Bug#1105820: Gnupg-in-debian considers comment packets invalid

[Daniel Kahn Gillmor]

Hi Sune--

Thanks for following up here.

On Fri 2025-05-16 19:41:54 +0200, Sune Stolborg Vuorela wrote:
> I'm not sure why all of this matters; there are others that expects gnupg in 
> Debian to validate and fail things in a similar way to gnupg-from-upstream and 
> gnupg-in-other distributions.

Debian also has a responsibility to reduce the attack surface of the
software it ships, even when upstream ignores reported risks and
vulnerabilities.

I'm going to walk through the timeline here, in case it's useful for
someone reading the archive.

The patch that you identified as problematic was offered to upstream,
and a CVE was indicated, with the intent to reduce the attack surface of
GnuPG.  There was no substantive response to this post for about three
years on the upstream bugtracker:

   https://dev.gnupg.org/T5993

Soon after Demi Marie reported the concern and offered a fix which
pushed back on accepting arbitrary packets, GnuPG upstream was publicly
warning against accepting *any* sort of padding-style packet, despite
the OpenPGP working group explicitly trying to adopt such a mechanism:

  https://mailarchive.ietf.org/arch/msg/openpgp/npCHOnOWEWVfvztmrkqs0w00NLk#

From that thread:

>>> Having [padding packets] in the protocol is a problem because
>>> applications taking care not to leak too much information will need
>>> to reject such messages and inform the user about a possible
>>> problem.

So it appears that to the extent that GnuPG upstream wants to avoid
leaks, they will *reject* padding packets that could serve as a side
channel.

Meanwhile, Werner had an opportunity during that discussion, to propose
that we should accept either packet type ID 16 (known in GnuPG as
PKT_OLD_COMMENT) or *any* experimental packet codepoint as a padding
packet.  But he didn't, leading me to believe that GnuPG would be
rejecting extra channels.

Your poppler changes stem from commits a few months ago, that *adopt* a
padding packet, in contravention of GnuPG's stated intentions:

  https://gitlab.freedesktop.org/poppler/poppler/-/commit/f0316ba62df9ce6d8e17a9349934b4a06df87e69

And, it looks like at least parts of Demi Marie's proposed fix from
T5993 are flowing into GnuPG upstream now, but not all of it.  At least
part of what is being held out (not adopted) is exactly the part that
implements what Werner suggested a careful OpenPGP implementation should
do.  And poppler is taking advantage of that gap between intention and
action.

Am i missing anything from this timeline?

> And poppler is released, used by others. Not only in Debian, but also
> in other places, and it generates these documents. We should not
> reject them just because we can.

How long as poppler been released with this functionality?  Who is using
it?  Has it been tested against any other PDF + OpenPGP implementation?

> Note that it is using GpgME to talk to GnuPG, not to do RFC9580 which GnuPG 
> does not support, so all references to RFC9580 is not relevant here.

The codebase says "PGP signatures".  yes, i agree that it's using GpgME,
but if we're talking about PGP, let's keep the terms straight.  The hope
is to be interoperable with other PGP implementations, right?

> And these private packets are fully compliant. It is in the spec after
> all.

What is in the spec?  Public key packets are *also* in the spec, but
they don't belong in a detached signature, which is what is described
here.  Nothing in any OpenPGP specification i've ever read suggests that
arbitrary packets can be included in any position in a detached
signature.  Indeed, GnuPG itself wouldn't accept private/experimental
packet 62 in that position, if i'm reading the code right.

> And as I wrote, these packets have been around since 1998, which is at least 
> way before I heard of GnuPG, let alone co-maintained it in Debian.

Where were they in 1998?  The ones you're raising as a must-fix scenario
about look fairly novel to me, less than a year old in Poppler,
apparently released without interoperability testing.

> In a the signed part of a PDF file, it is described that the signature is 
> stored in a specific part of a PDF file (The signature covers bytes A to B and C 
> to D (and the signature needs to be stored between B and C)), so there this 
> hole that contains the signature, but given the location in the file needs to 
> be specified before signing the data, it must be bigger than the expected 
> signature size. 

Thanks for this breakdown.  I agree it seems like a challenging
engineering problem with a bunch of finicky constraints.  It seems like
the discussion on how to do it safely in poppler might belong over on
https://gitlab.freedesktop.org/poppler/poppler/-/issues/1595

> Given that there already is a battle tested package parser in GnuPG

The point of T5993 is that it is *not* in fact a battle-tested packet
parser.  Rather, GnuPG has been shipping a much broader attack surface
than it needs to for years, *and* has been declining to reduce the
attack surface even following sensible recommendations from their lead
developer.  Please don't use recent changes in Poppler to discourage
further improvements in GnuPG or other OpenPGP implementations.

> Currently, the goal is for users to be able to sign and validate documents 
> without having a properly issued (likely governmental) S/Mime certificate on 
> multiple operating systems.

I fully support this goal, and i'd love to see it happen in a way that
is effective and interoperable.  Happy to follow up on
https://gitlab.freedesktop.org/poppler/poppler/-/issues/1595 if you'd
like to try to figure out how to do that safely.

> But that would require understanding the packets rather than just passing it 
> on to the underlying implementation, thus complicating the code and increase 
> complexity of poppler.

yes, agreed.  It looks like you're now working for g10code.  Perhaps the
way to improve this is to update GnuPG to be able to specify a target
size of the emitted packet?

> A packet parser alone would likely double the amount of code needed in Poppler 
> for this feature.

I agree that asking Poppler to manually parse OpenPGP packets would be a
mistake.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20250516/a3e16107/attachment-0001.sig>