Hacker News Reader

Comment by y_xc | Hacker News Reader

"The exploit was caught promptly, so almost no users were affected. Debian sid, Fedora Rawhide, the Fedora 40 beta, openSUSE Tumbleweed, and Kali Linux all briefly shipped the compromised package."

One thing that is noteworthy is that Kali Linux integrated the backdoor briefly.

So we should have a discussion about security of distros packaging speed. Is it more secure to integrate all patches as fast as possible or is it more secure to wait a bit until it is being tested elsewehere. The "elsewhere" would catch the bad effects then. Integrating security patches as fast as possible could be very costy.

View on HN

> Is it more secure to integrate all patches as fast as possible or is it more secure to wait a bit until it is being tested elsewehere.

That's a chicken/egg argument. Someone needs to be "elsewhere". Integration testing is absolutely part of security defense in depth architecture. In point of fact this was caught by running Debian testing. Delaying inclusion would have delayed discovery.

Exactly that is my fear, too. It's like zero trust in everything. - Don't trust that any other party do the security testing for you - Don't trust any developer, it could have malicious intents - Don't trust the patches, they could introduce bugs/backdoors/...

So we're straight going in the direction of protectionism and isolation. Wouldn't that be a big step back for the whole OSS/FOSS community?

One thing I read the xc-writeups last days (I think it was here https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...) was that we at least shouldnt trust any devs/maintainers that have no online identity. Though the argument that you could create a fake ID is possible. So I'm still obsessed from the question, what are the lessons learned for the community from this and how restrictive the participation in OSS will become.

I don't think that's quite right: Trust the community. Trust the process. Sure, any one actor might be compromised, but that will be rare and exceptional. So build layers such that their bad actions get detected and corrected.

Some parts of that aparatus worked poorly in this case, it's true: xz had a single maintainer who turned out to be susceptible to a deliberate human engineering attack, and yet was trusted to be linked into the some of the highest-trust parts of the system. That's bad, and we should work to avoid that kind of situation in the future.

But other bits worked very well: multiple downstreams detected the flaw (though only Andres saw it for the attack it really was), and it was corrected before it reached any production releases. The community as a whole is set up in the right way and doing the right things.

It probably depends on what's being updated in the new version. If it's a vulnerability fix, then fast is good. If not, then waiting a little bit is ideal.

Not sure how that would work in an automatic way without some sort of tagging system marking it as "critical" but that could be abused by bad actors too.

Most major distros include mechanisms to install packages not security updates, either via the package manager, or through specific repositories.

Wasn't Debian testing also affected? That should have affected some people's PCs.

Yes, it was. And by that, for instance also all docker images that derive from debian:testing, which is not that uncommon.

that was the whole reason this was caught this early, because Andres Freund was runnig Debian Testing (or Unstable)

Reply on news.ycombinator.com