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
signature.asc
Description: PGP signature
