A backdoor in xz
A backdoor in xz
Posted Mar 30, 2024 2:44 UTC (Sat) by helsleym (guest, #92730)In reply to: A backdoor in xz by atai
Parent article: A backdoor in xz
> "He has been helping a lot off-list"
That makes the activities of "Jia Tan" harder to audit and could even have been why they diverted discussion off-list. I'm sure it seemed innocuous to the maintainer but thanks to hindsight it seems like a significant social element of this attack.
(source: https://www.mail-archive.com/xz-devel@tukaani.org/msg0057... )
Posted Mar 30, 2024 10:20 UTC (Sat)
by nim-nim (subscriber, #34454)
[Link] (3 responses)
The pseudonym may or may not point to a specific country.
The pseudonym holder may or may not have his own credentials compromised.
The pseudonym holder may of may not have had a visit from criminal groups or some agency that made him a proposal he could not refuse.
The pseudonym holder may have been working all this time for those groups, that may be as much interested in securing their own systems as in compromising the systems of others. Or he may be a disgrunted (ex-)employee, retaliating for something we do not know about.
Someday soon it may be an emergent malicious AI masquerading as a person (or just some catastrophic mistake in the way someone trained his model).
The possibilities in the brave new world we live in are endless. It is pointless to speculate or try to audit people at this point. Making builds more transparent and easier to check and audit is what is needed.
Posted Mar 30, 2024 16:06 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (2 responses)
It is harder to exploit but inserting some memory corruption in C/C++ is orders of magnitude more discreet than this blunt takeover of project ownership. Even better: you get more than one shot at it because you can plausibly pretend it was a genuine mistake. Cause it so often is.
Any spy agency that hasn't successfully done this yet in a variety of open-source projects is incompetent and its management should be fired.
> Making builds more transparent and easier to check and audit is what is needed.
Amen.
And of course: more code reviews, static analysis, test coverage, valgrind, safer languages, etc.
Basically just slow down; less code with more quality. The opposite of what corporations and people want.
Posted Mar 30, 2024 16:36 UTC (Sat)
by rra (subscriber, #99804)
[Link] (1 responses)
It's tricky, though, because one of the ways to get more quality is to realize that some of the foundations are shaky and built on a bunch of poorly-thought-out principles. But if you rebuild them, that is a form of speeding up, since it requires changes by everyone else to move to the new thing.
I use a variety of software on a daily basis that, so far as I can tell, has worked correctly for years. In some cases I've been tempted to adopt it and maintain it as part of that effort in slowing down and improving quality. But probably 95% of the time when I look at the source to some old program that I have come to rely on, it's written in janky C with global variables all over the place, static buffers, no comments, and a code flow that I find difficult to follow. I have rescued some of my own software from such a state through the power of sheer embarrassment, but I've yet to have the oomph to rescue someone else's software.
We have an enormous maintenance problem, and I'm not sure what slowing down and writing less code with more quality looks like in the face of that maintenance problem. It's one of the reasons why I'm somewhat sympathetic to the folks who would prefer to rewrite the world. It looks like speeding up and writing more code, the opposite of what you're correctly advocating, but the advantage of a clean slate is that it's a lot easier to add standards for slower work and higher quality when starting from scratch than it is to retrofit them to an existing community, or even an orphaned code base.
(And this is all apart from the fact that slower and higher quality is more expensive, and we lack any effective mechanism to fund resilience, sustainability, and going slower. Not just in software, but in most human endeavor. Most social and political forces are pushing in exactly the opposite direction, as you correctly note.)
Posted Mar 30, 2024 17:11 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
To be clear: if "rewriting the world" works better and faster than raising the bar on an existing and time consuming code base then I'm all for it.
Either is much slower than merging untested and barely reviewed commits.
A backdoor in xz
A backdoor in xz
A backdoor in xz
A backdoor in xz