Live data from Hacker News

Reflections on Distrusting xz

joeyh.name

251–260 of 335 posts

Re: Reflections on Distrusting xz

#251
post #184
post #179

Earlier quoted context omitted.

I'm not sure why people keep misidentifying the problem as "lack of funding". Lasse Collin was doing fine as a maintainer up until Jia Tan showed up. He was psy-op'd into believing there was a crowd of angry people eagerly awaiting a new release when there wasn't. No real person was unhappy with the way he'd been maintaining xz.

I'm not saying money would absolutely fix the issue, but I could also see it helping. If Collin was approached by a government that said "Hey, the thing you're maintaining is important, if you want, we'll fund 2 additional full-time maintainers that can contribute based on your guidance", maybe Collin would be in a better position to ensure the Jia Tan contributions were genuine and proper.

If I was the maintainer and was approached by government telling me, "hey, here are two folks who're going to be two new full-time maintainers and we're funding them" I certainly would be worried.

Re: Reflections on Distrusting xz

#252

Earlier quoted context omitted.

>Are software developers (finally?) going to remove dependencies(now proven to be liabilities!), causing months of refactoring and rewriting, without any other progress? How is that even a possibility? xz was very useful software, which can only exist if people with significant knowledge put effort into it. Not every OSS project has the ability or resources to duplicate that. The same goes for many, many other depend…

Agreed. More than that, there's not much of a way to preven these kinds of attacks, period, whether in software or otherwise, if the perpetrator is some intelligence agency or such. For threats lesser than a black op, the standard way of mitigating supply chain attacks in the civilized world is through contracts, courts, and law enforcement. I could, in theory, get a job at a local food manufacturer, and over the cou…

>the only way I see to properly mitigate these kinds of threats is to ditch OSS and make all software commercial again (and legally force vendors to stop with the "no warranty" clause in licensing).

Which just pushes the problem to commercial companies getting a 'friendly' national security letter they can't talk about to anyone stating they should add REDACTED to the library they provide.

Re: Reflections on Distrusting xz

#253

Earlier quoted context omitted.

>> what's on it is no one's -ing business in a professional context. > The age of self censorship :) I find this amusing. I would also like to know what you hoped to achieve by self censoring the word fucking in your message above. - HN doesn't block posts with any kind of "profanity" filter - You didn't spare anyone from the profanity, since we all knew exactly what you were saying/thinking So I'm really curious wha…

That one amuses me because of a character in a (iirc) fantasy book that swore all the time but used just -ing everywhere. Sadly I don’t remember what character of which book…

It's Mr Tulip, of Terry Pratchett's The Truth.

Re: Reflections on Distrusting xz

#254
post #179

Earlier quoted context omitted.

I'm not sure why people keep misidentifying the problem as "lack of funding". Lasse Collin was doing fine as a maintainer up until Jia Tan showed up. He was psy-op'd into believing there was a crowd of angry people eagerly awaiting a new release when there wasn't. No real person was unhappy with the way he'd been maintaining xz.

Funding aside, single individuals being responsible for software is not a good thing, see bus factor.

Fortunately there was Jia Tan to help him. /s

Re: Reflections on Distrusting xz

#255
post #8

One thing that comes to mind is that “Jia Tan” might be more accurately seen as a “sleeper” of some sort: a foot soldier who infiltrates a juicy open source project and waits for further instructions; backdooring sshd might not have been part of the original plan. Which raises the concerning question of how much more sleeper maintainers there are.

>Which raises the concerning question of how much more sleeper maintainers there are. Given how easy the infiltration is and how extremely hard to detect it is, likely a lot. For an intelligence operation it is also extremely cheap, you just need a few knowledgeable developers spending some time each week on the project. The upside being a backdoor into a significant portion of infrastructure, the downside being wast…

I believe LLMs could be useful here as a component of pre-commit hook.

Re: Reflections on Distrusting xz

#256

Earlier quoted context omitted.

> But this suggests reimplementing xz/lzma. If there is a known good copy of the repo from before the attacker had sufficient access to alter history, then that is an acceptable starting point. From there you look at each update since and assess what they do to decide if you want to keep (as they are valid improvements/fixes) or discard them. If some are discarded, then later ones that are valid may need further work…

> If there is a known good copy of the repo from before the attacker had sufficient access to alter history, then that is an acceptable starting point. I heard someone calling themselves “Honest Ivan” has just the thing, totally trustworthy.

Given how spread the copies could be, and that we know when the bad actor gained the level of control needed to upset history, or if we want to go further back when that user started making contributions, it is likely that by comparing many claims we can prove to a reasonable level of assurance¹ that a given version is untouched in that regard.

Furthermore the original main maintainer seems to have a repository with an untouched lineage. While true paranoia says they can't be trusted without verification (he could be under external influence, as could anyone) I think we can safely give their claims more credence than those of Honest Ivan.

--

[1] to the level where a clean-room implementation is not significantly less likely to be compromised by external influence with bad motives.

Re: Reflections on Distrusting xz

#257

There seems to be a fundamental misunderstanding with a lot of these writeups. Are they 100% sure history was not rewritten at any point? Going back in time on the repo prior to listed involvement doesn't do anything as the attacker had full control. Starting from the last signed release prior to their involvement is the only way to actually move this forward (history may be fully lost at this point), the rest is pos…

People think git is immutable. It is not.

Well, it is and it isn't: It has mutable pointers (branches and tags) to immutable nodes in a graph (commits).

Re: Reflections on Distrusting xz

#258
post #213

Earlier quoted context omitted.

> If you try to, then others will notice that the hashes mismatch and that their HEAD diffs uncleanly. So it relies on a human noticing and acting upon it. People not noticing backdoors being merged into the project is kinda the source of this problem.

You can automate checks for if a large part of the previous git history suddenly changed. You can't automate checks for malicious code.

That relies on some heuristics which can be worked around, unless you disallow rewriting history.

But the bigger issue is that this is some theoretical system which is not present in most git repositories.

Re: Reflections on Distrusting xz

#259
post #8

One thing that comes to mind is that “Jia Tan” might be more accurately seen as a “sleeper” of some sort: a foot soldier who infiltrates a juicy open source project and waits for further instructions; backdooring sshd might not have been part of the original plan. Which raises the concerning question of how much more sleeper maintainers there are.

My assumption is that this was state sponsored mass surveillance campaign of some kind but God knows what exactly they were looking for. I think if backdoor was discovered 2 or 3 months later, we maybe could understand better what they wanted to do. My speculation is that they wanted to build a massive botnet and then snoop on machines' processes and traffic looking for something. It's hard to speculate because lucki…

I find it intriguing that out of all the speculative comment threads I've read so far, none of them have suggested it was Microsoft attempting to make FOSS look bad/vulnerable.

Re: Reflections on Distrusting xz

#260
post #101
post #60

Earlier quoted context omitted.

That's exactly what they do, though: https://cloud.google.com/assured-open-source-software/docs

Google also does code reviews for some commonly used projects (or maybe that's part of the same thing? I don't know). I went through that last year with one of my Go libraries. The idea is good, but the entire process is so bureaucracy-heavy and time-consuming that I found it both frustrating and entertaining in equal parts; like something out of Brazil (the film, not the country). So many emails, so many video meeti…

Brazil the country is also known for onerous bureaucracy
Post reply on HN