I think there are huge factors that push things both for and against open source here.

Yes, you get more eyes and people like Andres Freund.

However, if this had been a mole in a company, he wouldn't be able to hide behind a possibly anonymous fake persona and (likely) be immune from any consequences/fallout from this attack. It would be harder to gain entry in the first place, he would have needed a real identity. Background checks may not be a big hurdle, but they're at least something more than signing up for a GitHub account. He also wouldn't have had his posse of anonymous sock puppet accounts to add pressure to the original maintainer.

I also think that just being able to ramp up on liblzma and its dependencies to undertake this effort in the first place is a huge head start vs. trying to execute the same attack on a closed source corporate product.

At the same time, there are probably lower hanging fruits to attack if you really do get a mole inside a company, in addition to there being fewer eyes/opportunities for the attacks to be discovered as you pointed out.

I honestly don't know how all of these factors add up. I expect the argument opposite to yours to be raised (again) in the wake of this incident. I'd personally be hesitant to raise this argument (not that it matters here on HN).

> However, if this had been a mole in a company, he wouldn't be able to hide behind a > possibly anonymous fake persona and (likely) be immune from any consequences/fallout from > this attack. It would be harder to gain entry in the first place, he would have needed a > real identity.

Lots of companies hire remote workers sight unseen, and not all require proof of identity, and where they do, that proof can possibly be easily faked by someone willing to break the law.

Larger Open Source projects - e.g. Debian Developers, also have real-identity verification through chain of trust.

> Background checks may not be a big hurdle, but they're at least something more than > signing up for a GitHub account.

GitHub doesn't allow more than one free account per person. Companies might not look for employees sharing an IP address as much as GitHub does.

> He also wouldn't have had his posse of anonymous sock > puppet accounts to add pressure to the original maintainer.

Depending on the software, it might not be that hard to be a customer (or even pretend to be an employee of a known customer, if they aren't validating incoming requests claiming to be from customers enough) and add pressure for features that will provide cover for a backdoor, or even for a product that isn't a commercial success to be handed over to an external developer.

And yet industrial espionage in companies is quite common, by both competition and, if you’re big and important enough, state (yours or enemy). The means are different, though.

Organisations shield moles and infiltrators very effectively. They are rarely alone. It may be harder to get in as an outsider, but once in they've protections a lone wolf does not enjoy.

You can save a lot of time reading John LeCarre novels and take a short summary like this one of Adam Curtis [0].

If you watched the recent Oppenheimer film you'll know the name Klaus Fuchs. But what about Guy Burgess, Kim Philby and Anthony Blunt? If MI5, MI6 and GCHQ are. almost by tradition stacked to the rafters with defectors and spies, enclaves of enemies within, and enemies within enclaves of enemies... how does anyone expect a commercial company motivated by money and with such a weak perimeter as a "job market", to do better?

Trust does not have an organisational solution.

[0] https://www.bbc.co.uk/blogs/adamcurtis/entries/3662a707-0af9...

In a corporate proprietary code base this is REALLY easy. Just commit a bug. Happens every day, everywhere. Just that normally these are mistakes. You can easily mask a deliberately inserted exploitable bug as a mistake. Make the code a bit convoluted, leave out a crucial corner case from your test, slip this in in a moment when your code reviewers have time pressure and/or are stressed somehow, and even if you are caught, the plausible deniability is convincing. How many eyes will see it after the fact? None.

It’s pretty intellectually dishonest to call this a big win for open source. It’s completely and utterly bonkers that this was noticed. Unthinkably low odds. There are certainly other backdoors out there like this, already in production.

If this happened on a proprietary software project, …I have verified proof of identity documents for everyone on my team. These can of course be faked or fraudulently obtained, but it heightens the barrier to entry and leaves more of a paper trail. That’s not something that we have in this scenario. There’s way more give and take between open and closed source than open source purists make out. They just like the idea of being able to see source code.

I see people saying "this almost succeeded". It didn't almost succeed, it succeeded entirely. It made it to production, for a long time (? I'm not sure how long it was in repos).

Success is making it to some machine, and then it's "how long it's successful for". Who knows how many other such vulnerabilities there are, and the openness of the source didn't protect us as quickly as we thought it would.

> It made it to production, for a long time

Did it? At least in Debian, where it was found in the first place, it only existed in sid/unstable and I think perhaps in testing. It never made it into stable which is the only thing you should be running on a production system.

I think in Fedora it was also only in a testing or RC of the next stable version but I'm not sure. Also unsure about others. I have seen several distros putting out advisories (Gentoo, Arch, OpenSuse and more) but I didn't go into the specifics.

I don't know specifics either, but Debian stable has years-old packages, so I'm not sure if it's a good indicator of how widespread this got. If it's in the latest Ubuntu release, I'd say it's pretty successful.

Fortunately, it didn’t make it into an Ubuntu release: https://discourse.ubuntu.com/t/xz-liblzma-security-update/43...

Though it was frighteningly close, 24.04 is scheduled to be released on April 25.

Wow, ok, that's close. I wonder how many have actually made it.

My impression is that it did not get into latest Ubuntu, they were in the process of trying though.

The end goal seems to have been to get it into the LTS releases of rhel and Ubuntu. Since this was a valuable it's probably something kept around for when other methods fail. I doubt it would be used before the really valuable systems are compromised (rhel and Ubuntu in cloud and governments)

I don't personally know anyone who would run any Debian release that's not stable on production systems. On your desktop? Fine. I do it myself. On a server, with ports open to the public Internet that's a big nope.

There's nothing wrong with Debian stable having years-old packages either. In any case:

> The current "stable" distribution of Debian is version 12, codenamed bookworm. It was initially released as version 12.0 on June 10th, 2023 and its latest update, version 12.5, was released on February 10th, 2024.

https://www.debian.org/releases/

That's just over 1 year. Sure, packages themselves will be older than that since they take some time soaking frozen in testing before they become part of stable but that's generally a good thing.

In any case, if there's pressing need for some newer packages, it's always possible to use apt pinning to pull those on top of a stable base.

I didn't say there's anything wrong, I meant that choosing the OS distribution with the oldest packages isn't an indication for how widespread the distribution of this package was.

I was initially responding to

> > It made it to production, for a long time

I never said it didn't make it to production. I was asking if that's the case, and giving one data point.

It apparently didn't make it into Ubuntu LTS either, so there's another one.

If you have information that proves or disproves either point, please present it.

> Yes, this almost succeeded... but can you imagine how many scenarios where someone such as Andres Freund would have found irregularities, but then.. what? Just had to report it to some webpage's contact page? Without being able to even dig further?

You should check the thread posted yesterday, the Lastpass guy who raised a PR for a go binding for xz but was otherwise unrelated to this fiasco already faced a bit of questioning regarding their motivations from their employer based on a user reporting them from a contact form.

Moreover, many companies already have information from background checks, and in certain countries, they also have the tax identification number of the employee which can pretty much identify who put in the backdoor.