c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
Community Rules
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]
Notable mention to [email protected]
Supporting projects - either with money or helping with code review in a transparent way.
The xz maintiner was burned out, bullied for being negligent (likely by the attackers), had personal mental health issues and became the first victing of this backdoor long before the code was merged.
Ideally, developers on projects like xz would band together. Projects like that rarely see much development, but when they do, it's a lot all at once. So devs being able to move between a handful of projects would lighten the load on everyone.
So if you maintain a FOSS project, consider helping out with others related to your project (e.g. dependencies), and consider reaching out to devs of those projects for help on yours as well. It would be awesome to have a few pockets of dev coalitions so devs feel more comfortable taking a step back.
That's a very good idea. Support your dependencies' maintainers people.
Is this just an article from The Register inside an msn wrapper with additional enshittification on top?
Original article and comments: https://www.theregister.com/2024/04/06/register_kettle_xz/
Does anyone know of a list of at-risk projects (i.e. popular projects with only one dev or one primary dev)? I'm interested in helping out, but I need a place to start.
From what I've read, thus-far, prohibiting autotools would be a good 1st-step.
Then auditing all the damn ocean-of-vulnerability-in-a-single-crufty-swamp dependencies, & getting committed about clarity & accountability in packages, would probably be required.
I read an article, a couple years ago, about web-frameworks..
The guy doing the writing said he found they were often malware, or corrupt, or trojans, or utter-bullshit..
Haskell's got a kind of mantram: don't bring in a whole framework, just compose what you need, yourself, together.
Its a granularity-difference.
Requiring a framework, which itself requires other frameworks, as that guy was pointing-out ( he wasn't interested in Haskell ), is a liability nightmare.
But the culture of just having an infinite bring-in of frameworks & libraries, so one can write a little, easy code, is a culture that is biting the world's security in the ass.
It cannot be, that people just include everything from everywhere, & somehow have secure/trustworthy systems.
To have a secure, trustworthy system, one needs to know that one has disincluded corruption/malicious-code.
That requires limiting what's included, that includes auditing, that includes accountability, that includes having understandable, sufficiently-clear stuff that one is including.
Consistently, at all levels, relentlessly.
It's a chain: you cannot have a weak-link without compromising the whole chain.
You cannot compromise ANY subsystem in a distro, & have a trustworthy distro.
There are 2 contradictory paradigms: the "magic bullet paradigm", which doesn't care how much rot, compromise, anything, so long as they include the "magic bullet" which takes-out the competitor..
.. vs the "no weak-points, whatsoever, paradigm", which doesn't rely on magic, it relies on defense-in-depth, and carefulness, and everybody working coherently, etc, in order to disallow corruption/malicious-actors any leverage/grasp on us.
They are cultures, not just ideas.
Some people cannot tolerate a "no weak-points" culture, they "NEED" to compromise things ( I don't care about the bugs, get more features in!!" ), and they must be put out into the other organizations/operations, because they CANNOT tolerate careful-paradigm.
It truly is a culture, or "religion", and there's no faking it.
Look to OpenBSD, & see what it takes to be like them..
I like the Go philosophy here: if you just need a function, copy the function, don't import the whole module. A little code duplication is fine, and it significantly narrows your attack surface.
But while I agree with your point in general, you really missed the mark here. The problem with xz wasn't pulling in sketchy dependencies, it was online bullying of a burned out FOSS dev. That's not a technical problem, but a support one.
The solution to problems like the xz vulnerability must be about supporting FOSS devs. Review code, donate money, join mailing lists, etc. Be the support these devs need, and push back against outsiders who seem to be engaging in bullying.