On Tue 2025-05-27 20:34:40 +0200, Sune Stolborg Vuorela wrote:
> On Tuesday, May 27, 2025 6:14:53 PM CEST Daniel Kahn Gillmor wrote:
>> I can take a look and see whether it's possible to get both kinds of
>> benefits -- standards compliance and reduced attack surface -- but i'd
>> certainly appreciate some upstream support in doing so.
>
> Did you check the upstream committed patch to deny compressed packets unless
> specifically compat-enabled?
>
> https://dev.gnupg.org/rG23ccad05c68005b580c7b209e2242bb93893af62
Yes, i'm happy to see at least this part of the attack surface reduction
being taken seriously by upstream. I welcome this change in behavior,
where compressed packets are not accepted in an OpenPGP certificate.
I'm less keen on the patch's addition of the "compatibility mode" in
this patch. Each such mode effectively doubles the scope of any attempt
at comprehensive testing of the GnuPG tooling (you have to run any tests
once without the mode, and once with it), and makes triaging bug reports
more challenging (you have to figure out whether the user was in the
mode or not). If there are known, unfixable, important uses for a
particular compatibility mode, then i get it. otherwise, i think
avoiding the complexity is a better option.
I also don't think this patch addresses detached signatures, which are
really the most common place where attacker-controlled data will appear.
I think the most common case for GnuPG use today is where a user already
has a trusted certificate (delivered e.g. by their operating system or
some other trusted channel) and they're verifying the authenticity of a
downloaded piece of infrastructure (e.g. software update, or even an
OpenPGP-signed PDF ☺). That's typically the detached-signature form of
operation, and the patch you're pointing to doesn't cover it at all.
I don't mind tooling that skips blindly over unexpected non-critical
packets without parsing their internals or trying to handle them: it's
the parsing+handling that is the dangerous part, given the complexity of
the GnuPG codebase. The packet framing on its own should be
comparatively less dangerous and better tested.
But if we can't avoid parsing+handling, then bailing on unexpected
packets seems like a plausible first-order line of defense. And I
haven't had the time to figure out how to avoid parsing/handling. If
you have other insights or suggested patches, i'd be happy to review
them.
Thanks for looking into this further with me.
Regards,
--dkg
