Re: Sourceware mitigating and preventing the next xz-backdoor

Jonathon Anderson <[email protected]> writes:

> On Tue, 2024-04-09 at 14:50 -0700, Paul Eggert wrote:
>
>  On 4/9/24 14:40, Jeffrey Walton wrote:
>
>  Code provenance and code integrity was not enforced. Part of the problem is the Autotools design. It is from a
>  bygone era.
>
>  No, Andreas is right. This isn't an Autotools-vs-Meson thing.
>
>  Most of the Autotools-based projects I help maintain would have been
>  immune to this particular exploit, partly because they don't maintain
>  their own of Gnulib .m4 files. Conversely, any Meson-based project that
>  had the same sort of out-of-repository sloppiness and lack of review
>  that xz had, would be vulnerable to similar attacks.
>
> Xz doesn't either, the exploit was unique to the distributed make dist tarballs. Which is an Autotools quirk present in
> all Autotools projects.
>
> I won't deny that a project could use Meson and be sloppy, a project could use SSL/TLS/whatever and be completely
> insecure. But Autotools encourages and semi-requires this sloppy behavior, and CMake and Meson strongly discourage this
> behavior.

Indeed. Talking about things in the context of "how can we make it
easier to spot" is a good thing. Obviously if we're trying to resist a
state actor, things are very hard. It doesn't mean don't bother.

>
> -Jonathon

thanks,
sam

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZhW8018UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB
NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv
by5vcmcACgkQc4QJ9SDfkZBDdQEAvqOBttVsMC8ryEv/1NGktqs6ojkcTeuJQUv7
SBP8UEwA/2f+H2tcAQeQLfRxWE5OpwDw8Y1eTmJ08DabUN5/kScI
=wbXJ
-----END PGP SIGNATURE-----