• @[email protected]
    link
    fedilink
    English
    119 months ago

    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.

    • @[email protected]
      link
      fedilink
      English
      59 months ago

      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.

  • @[email protected]
    link
    fedilink
    English
    49 months ago

    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.

  • @[email protected]
    link
    fedilink
    English
    -49 months ago

    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…

    • @[email protected]
      link
      fedilink
      English
      6
      edit-2
      9 months ago

      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.