open source and code review

Posted Nov 12, 2024 6:07 UTC (Tue) by josh (subscriber, #17465)
In reply to: open source and code review by ballombe
Parent article: The top open-source security events in 2024

I think the xz backdoor was an example of what code review *doesn't* easily catch, and a demonstration that code which is resistant to code review should be presumptively rejected by default. Checking in autogenerated files, checking in binaries, having bits that can't be reproduced on non-developer systems, anything that thwarts code review shouldn't fly.

It was also an especially painful demonstration of https://xkcd.com/2347/ and what happens when single-point-of-failure projects get handed off to new maintainers, or pressured to get handed off to new maintainers.

to post comments

open source and code review

Posted Nov 12, 2024 12:20 UTC (Tue) by pizza (subscriber, #46) [Link]

> I think the xz backdoor was an example of what code review *doesn't* easily catch

As the saying goes, it takes two to tango.

The problem with xz was that that the one supposed to be reviewing contributions (ie the only active maintainer) was actively malicious, and there was nobody else willing/able to perform meaningful reviews of that maintainer's contributions.

> Checking in autogenerated files, checking in binaries, having bits that can't be reproduced on non-developer systems, anything that thwarts code review shouldn't fly.

They didn't check in autogenerated files; in this case the dodgy configure script was only in the release tarball, not the public repo. Meanwhile, the binary file was flagged as a defective file used in regression testing, something quite common for test suites, and it is the overwhelming norm for release tarballs to contain generated configure/build scripts versus what is in the repositories. It also takes "non-developers" to determine that things can't be reproduced on "non-developer systems".

Tl;dr: Calls for "maintainer diligence" are meaningless in the face of actively malicious maintainers.