4 ms·
You're not wrong, but IMO that isn't the real problem. The real problem is the combination of highly popular core open-source utilities with near-zero maintenan
by ufmace 3y ago
You're not wrong, but IMO that isn't the real problem. The real problem is the combination of highly popular core open-source utilities with near-zero maintenance resources.
This was all possible because XZ, despite being effectively everywhere, has one actual part-time maintainer who had other things going on in his life. That also means that there's nowhere near enough resources to redo the build system to some more secure alternative. If they had, say, 10 enthusiastic and skilled volunteer contributors with plenty of free time, they could do that, but then a new person appearing out of nowhere with a few helpful commits would never have a chance at being made an official maintainer or sneaking sketchy tools and code past the other maintainers.
Not that I'm blaming XZ or the real maintainer. Clearly whoever was behind this was looking for the weakest link, and if it wasn't XZ, it would have been something else. The real problem is the culture.
So I guess what this really means is someone at a big corporation making Linux distros should audit their full dependency tree. Any tool in that tree that isn't actively maintained, say at least 3 long-time active contributors, they should take over one way or another - whether that's hiring the current maintainer as a full-time remote employee, offering to buy out the rights, or forking and running under their own team.
I'm not necessarily super thrilled with that, but I guess it's the world we live in now.
- bhawks 3y agoThe overworked solo maintainer is a problem. However I've seen way too many projects where individuals in the 'team' are able to carve out impenetrable fiefdoms where they can operate with wide latitude. I could see a Jia Tan being able to pull this off in a team context as well - bigger teams might even be weaker. (Everyone welcome Jia - he's going to write test cases and optimize our build process so everyone can focus on $LAUNCH_DAY)
- pch00 3y ago> So I guess what this really means is someone at a big corporation making Linux distros should audit their full dependency tree. This is it precisely. When you're paying Redhat for an "enterprise" Linux then that guarantee should extend down their entire software stack. Just getting the odd backported patch and so-so email support no longer cuts it.
- peteradio 3y agoWhy do utilities need constant fucking updates? Why do they need maintenance? New features are entirely optional and if what you want to do isn't supported aka xz java, uhh, get fucked or do it yourself.
- Dunedan 3y agoI believe software of a certain complexity can't be finished and will always need updates, even if you exclude new features, as the whole eco system of hardware and software is constantly evolving around it. Here are a few reasons why: - bug fixes (as every non-trivial software has bugs) - improved security (as the kernel adds security functionality (capability dropping, sandboxing, ...), software can utilize this functionality to reduce its attack surface) - improvements of existing features (e.g. utilizing new CPU extensions or new algorithms for improved performance)