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.
Reflections on Distrusting xz
251–260 of 335 posts
Re: Reflections on Distrusting xz
#252Earlier 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…
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
#253Earlier 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…
Re: Reflections on Distrusting xz
#254Earlier 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.
Re: Reflections on Distrusting xz
#255One 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…
Re: Reflections on Distrusting xz
#256Earlier 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.
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
#257There 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.
Re: Reflections on Distrusting xz
#258Earlier 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.
But the bigger issue is that this is some theoretical system which is not present in most git repositories.
Re: Reflections on Distrusting xz
#259One 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…
Re: Reflections on Distrusting xz
#260Earlier 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…