> It's also good to keep in mind that this is an unpaid hobby project. That's the root cause. At some point a corp/gov consortium needs to adopt key projects and hire out the maintainers and give them real power and flexibility, perhaps similar to the way a nation might nationalize key infrastructure. But this is against the core ethos at some level. Freedom and safety can be antagonistic.
> gov consortium Personally I wouldnt trust a govt to not backdoor everything.
Timeline of the xz open source attack
321–330 of 482 posts
Re: Timeline of the xz open source attack
#322Maybe one of the outcomes of this could be a culture change in FOSS towards systematically banning rude consumers in Github issues, or, just in general, a heightened community awareness making us coming down on them way harder when we see it happen.
The Jia Tan character was never rude. If you make rudeness the thing that throws a red flag, then ‘nice’ fake accounts will bubble up to do the pressuring.
I think we need to start paying more of these open source maintainers and have some staff/volunteers that can help them manage their git hub issue volume.
Re: Timeline of the xz open source attack
#323> It's also good to keep in mind that this is an unpaid hobby project. That's the root cause. At some point a corp/gov consortium needs to adopt key projects and hire out the maintainers and give them real power and flexibility, perhaps similar to the way a nation might nationalize key infrastructure. But this is against the core ethos at some level. Freedom and safety can be antagonistic.
You are implying that governments are more technically competent and more trustworthy than open source communities..
Re: Timeline of the xz open source attack
#324I think one of the good things to come out of this may be an increased sense of conservatism around upgrading. Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Raising the bar for accepting changes can also reduce the churn that makes so much software unstable.
Everyone being on different versions results in something like a moving target
Re: Timeline of the xz open source attack
#325"It's also good to keep in mind that this is an unpaid hobby project." ~ Lasse Collin, 2022-06-08. As someone working in security, the fact that _foundational_ pieces of the computing/networking rely on motivated individuals and essentially goodwill is mind blowing. There are great aspects to the FOSS movement, but the risks – particularly the social engineering aspects as demonstrated here – and potential blast radi…
Sorta but flawed relevant xkcd: https://xkcd.com/2347/ I don't see how this is any strongly different than some unappreciated skill worker in a corporation. Its interesting the double standard we have for FOSS. Meanwhile in the commercial world, supply chain attacks are commonplace and barely solicit headlines. Yes, FOSS needs to be able to address these kinds of attacks, but the world runs on the efforts of the low-…
Re: Timeline of the xz open source attack
#326I think one of the good things to come out of this may be an increased sense of conservatism around upgrading. Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Raising the bar for accepting changes can also reduce the churn that makes so much software unstable.
I highly encourage people to try freeBSD sometime. Give ports a try (although the modern sense is that poudrie is better even if you want custom-built packages). See how nicely everything works. All the system options you need go into rc.conf (almost uniformly). Everything is documented and you can basically operate the system out of the FreeBSD Handbook documentation (it's not at all comparable to the "how to use a window or a menu" level intro stuff the linux provides). You can't do that when everything is furiously churning every release. everything just works, everything is just documented, it's an experience when you're coming from linux.
and that forum post from 2007 on how to tweak a service script is probably still valid, because BSD hasn't had 3 different init systems over that timespan etc.
just like "engineering is knowing how to build a bridge that barely doesn't fall over", engineering here is knowing what not to churn, and fitting your own work and functionality extensions into the existing patterns etc. like it doesn't have to be even "don't make a bigger change than you have to", you just have to present a stable userland and stable kernel interface and stable init/services interface. the fact that linux doesn't present a stable kernel interface is actually fairly sketchy/poor engineering, it doesn't have to be that way, a large subset of kernel interfaces probably should be stable.
Re: Timeline of the xz open source attack
#327Earlier quoted context omitted.
An attack would look something like: 1. A new "test" is added to the xz-utils repository, and when xz is being built by a distribution such as Debian, the backdoor from the "test" is included into the xz binary. 2. The backdoored xz is distributed widely, including to a target vendor who wishes to from a Debian development environment compile a kernel for an embedded device that is usually used in a specific industry…
Note that none of these steps require the attacker to have any code in the kernel. The kernel patchset is completely orthogonal to the possibility of this attack, and seems to be benign.
Re: Timeline of the xz open source attack
#328One big take away for me is that we should stop tolerating inscrutable code in our systems. M4 has got to go! Inscrutable shell script have got to go! Its time to stop accepting that the way we've done this in the past is the way we will continue doing it ad infinitum.
Re: Timeline of the xz open source attack
#329Earlier quoted context omitted.
Yes the whole "let's take a mystery meat tarball from a repo that isn't the project repo" seems suspect. Github+ even has a scheme for signing artifacts such that you have some level of trust they came from inside their Actions system, derived from some git commit. This would allow the benefits of a modular build for a large product like a distro, while preserving a chain of trust in its component parts. +Not advocat…
as I wrote in a different thread, some projects don't have any source control. From the big ones - 7z, ncurses are both tarballs only.
Re: Timeline of the xz open source attack
#330Earlier quoted context omitted.
Sorta but flawed relevant xkcd: https://xkcd.com/2347/ I don't see how this is any strongly different than some unappreciated skill worker in a corporation. Its interesting the double standard we have for FOSS. Meanwhile in the commercial world, supply chain attacks are commonplace and barely solicit headlines. Yes, FOSS needs to be able to address these kinds of attacks, but the world runs on the efforts of the low-…
I think there is a fundamental difference between how corporations used to work and how open source typically works. In a traditional corporation, people would come to an office. It would be known where they live. If you would require something like (code) review, it becomes a lot harder to plant something. Obviously not impossible, but hard for all but the most dedicated attackers. In contrast, with open source and…