Hacker News Reader

Comment by mondrian | Hacker News Reader

A main culprit seems to be the addition of binary files to the repo, to be used as test inputs. Especially if these files are “binary garbage” to prove a test fails. Seems like an obvious place to hide malicious stuff.

View on HN

It is an obvious place for sure, but it also would have been picked up if the builds where a bit more transperant. That batch build script should have been questioned before approval.

By whom? The attacker have assumed the maintainer role. Nobody is reviewing.

There’s a severe and dangerous lack of paranoia in this dev space.

If I was letting someone maintain my codebase, I would 1 Billion percent be reviewing everything… if there was a binary added, I’d be building it myself and comparing the checksums.

Trust absolutely no-one. If you can give a close friend or a loved one a loan of money and it is so easy for them to never pay you back, it should be a reminder that devs you’ve never met are even more likely to scam you.

I think it's pretty pointless to speculate what you would have done considering the only reason "Jia Tan" was able to gain the access he did was because the original maintainer was burned out / busy with life / otherwise not able to dedicate the time needed for the project. If he can't maintain it himself he will be even less likely to adequately review his replacement. You can claim to have perfect opsec as much as you want but life has a way of screwing that up that no one is invulnerable against.

What's the point of having someone maintain your codebase if you have to do even more work than if you just did everything yourself?

pretty unhealthy attitude to live by tbh. almost better being burned by a malicious payload once every 10 years than live in perpetual fear of being constantly scammed

I think that depends on the context. If you're maintaining one of the most widely used packages that is directly linked to by libsystemd and is included by pretty much every Linux distro as part of the base system? Then maybe some measure of paranoia is justified.

I think the OpenBSD developers are right to be as paranoid as they are. Anyone who is maintaining a security critical system should be on guard against these kinds of attacks.

> If you're maintaining one of the most widely used packages that is directly linked to by libsystemd and is included by pretty much every Linux distro as part of the base system? Then maybe some measure of paranoia is justified.

But whose problem is that? systemd chose to link against liblzma, not the other way around. I doubt the xz maintainer(s) make money off of the project, and I'm assuming it's a spare-time/side-project type thing. Why should the fact that the library is included in every distro and is a dependency of systemd affect the xz maintainers' obligations? The leader of systemd has been variously employed by RedHat and Microsoft... if they're choosing to pull in an external dependency for systemd and then making money off of selling their Linux distros/cloud services, it would seem they're the ones that could afford to take on the burden of reviewing everything with a fine-toothed comb, not the xz maintaners.

I like your thinking. Absolutely. And very true. Even the folk who put the backdoor in will be getting paid. Everybody making bank, except Lasse.

Oh absolutely true for things like OpenBSD and such

Thing is, sec should be taken seriously across the board. I love what OpenBSD devs did - they seen an entire community of naive coders who didn’t give much of a crap about security and started something. I have used OpenBSD for 10 years and thoroughly recommend it to anyone to give you a good slap around the face for how shit is done right.

I sort of agree, I think we should collectively raise the level of paranoia slight, by some tens of percentages, to remove a lot of negative outcomes - but I wouldn't expect off-hand hobby devs to even remotely apply the same level of risk management as OpenBSD does.

Reply on news.ycombinator.com