On Thu, 27 Feb 2025 at 12:59:44 -0500, Daniel Kahn Gillmor wrote:
So this is definitely a change in GnuPG behavior, as reported upstream at https://dev.gnupg.org/T7547
The same behaviour change also caused a build-time test failure in src:ostree, https://bugs.debian.org/1098951 / https://github.com/ostreedev/ostree/issues/3386. libostree is designed to be able to receive signature validation errors (from either gnupg, its own ED25519-based signing scheme, or possible future signature backends, depending on build-time and runtime configuration) and report them to library users as a structured error code indicating what went wrong, at a level of granularity where it can distinguish between an expired key and a revoked key, for example. libostree's test suite asserts that it can provide this functionality, and I think I would tend to characterize this as "something that was previously possible no longer works, and the tests correctly caught this" rather than merely "the test-suite is brittle". Would you mind reassigning or cloning one of these bugs to gnupg to represent that, forwarded to T7547 upstream, while it's investigated? I think if libostree and notmuch are both showing test-suite regressions after this change, that does seem more likely to be a behaviour change in gnupg (and potentially an unintended one?) rather than simply libostree holding it wrong. If it's intentional that it is no longer possible to distinguish between different reasons why a signature does not validate, or if that's necessary collateral damage to avoid the DoS, then libostree will likely have to stop offering this feature, and instead report all GnuPG signature validation errors as "some unspecified thing is wrong with the signature" - but I don't think its upstream will want to do that without knowing that it's wontfix from GnuPG's perspective, and similarly I'm reluctant to apply downstream patches to weaken test coverage of a security-sensitive integrity check until we know they're necessary. smcv
