Is xz actually an open source success story?

It’s been just over two weeks since we all learned about a backdoor that had been slowly and carefully placed in the xz-utils library over a period of multiple years (if you’ve been under a rock and need the TL;DR, start here with my co-founder Luis Villa’s post). 

In that time, there’s been a ton of analysis both of the payload which would have been used for a future attack as well as the social factors which led up to the trusting of the malicious actor who went by the name “Jia Tan.”  And there have been a lot of discussions about broad, big picture questions about open source and supply chain security and what needs to change in a post-xz world. In fact, I joined five of our favorite maintainers for a discussion on exactly that topic last Friday that is worth a watch. 

But I’d like to channel my inner optimist and take a slightly different position on xz today:

xz shows the open source model working. 

There’s a well-worn saying in open source that, “given enough eyeballs, all bugs are shallow.” It’s a bit of a riff on a quote from Supreme Court Justice Louis Brandeis in 1913 that “sunlight is the best disinfectant” as a way to enshrine the importance of transparency. And open source is transparent in that people can actually look at changes, reason about them, and provide improvements or alternatives.

And that’s exactly how things played out with xz. Despite an incredible amount of obfuscation and effort to make this exploit difficult to find, a member of the open source community stumbled upon it because the code was freely available for inspection, triaged the issue, and disclosed it in a responsible way. 

If someone (or multiple someones) had gone to a similar level of effort to get a job working for a commercial software company and then made changes in that company’s proprietary codebase, the likelihood that it would have been noticed before it was broadly in the wild causing damage would be far, far lower. This isn’t to say that commercial software doesn’t have people reviewing changes and looking at them but there are just fewer ways that someone could notice or really dig in. 

We’re going to see a lot of fear, uncertainty, and doubt thrown around in the coming months about open source post xz, but that’s the thing I keep coming back to. Because this is open source, and the code was available, this exploit was uncovered before it was widely deployed. And because this is open source, we can have an ongoing and detailed discussion about how to prevent future exploits because all of the social interactions, all of the technical details, all of the code, is right there where everyone can see it and learn from it—in the open.

That’s an amazing display of the power of open source.

That said, we should still invest in reducing the likelihood of such efforts succeeding in the future, whether from copycats or more sophisticated actors. And for that, things like thinking more closely about binaries in source repos, moving away from having auto-generated files distributed and used vs regenerated at build time, and investing in paying maintainers to help ensure they can get the support they need are still important! Also thinking about ways to help improve distributed trust in an ever growing ecosystem of people wanting to contribute to open source. These are all conversations worth having as we look back at xz.

But don’t see xz as a failure of open source. Because in many ways it also shows us what is great about open source.