• JoeKrogan@lemmy.world
    link
    fedilink
    arrow-up
    48
    ·
    9 months ago

    I think going forward we need to look at packages with a single or few maintainers as target candidates. Especially if they are as widespread as this one was.

    In addition I think security needs to be a higher priority too, no more patching fuzzers to allow that one program to compile. Fix the program.

    I’d also love to see systems hardened by default.

    • Potatos_are_not_friends@lemmy.world
      link
      fedilink
      arrow-up
      40
      ·
      edit-2
      9 months ago

      In the words of the devs in that security email, and I’m paraphrasing -

      “Lots of people giving next steps, not a lot people lending a hand.”

      I say this as a person not lending a hand. This stuff over my head and outside my industry knowledge and experience, even after I spent the whole weekend piecing everything together.

      • JoeKrogan@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        9 months ago

        You are right, as you note this requires a set of skills that many don’t possess.

        I have been looking for ways I can help going forward too where time permits. I was just thinking having a list of possible targets would be helpful as we could crowdsource the effort on gitlab or something.

        I know the folks in the lists are up to their necks going through this and they will communicate to us in good time when the investigations have concluded.

    • Amju Wolf@pawb.social
      link
      fedilink
      English
      arrow-up
      31
      ·
      9 months ago

      Packages or dependencies with only one maintainer that are this popular have always been an issue, and not just a security one.

      What happens when that person can’t afford to or doesn’t want to run the project anymore? What if they become malicious? What if they sell out? Etc.

    • suy
      link
      fedilink
      arrow-up
      11
      ·
      9 months ago

      no more patching fuzzers to allow that one program to compile. Fix the program

      Agreed.

      Remember Debian’s OpenSSL fiasco? The one that affected all the other derivatives as well, including Ubuntu.

      It all started because OpenSSL did add to the entropy pool a bunch uninitialized memory and the PID. Who the hell relies on uninitialized memory ever? The Debian maintainer wanted to fix Valgrind errors, and submitted a patch. It wasn’t properly reviewed, nor accepted in OpenSSL. The maintainer added it to the Debian package patch, and then everything after that is history.

      Everyone blamed Debian “because it only happened there”, and definitely mistakes were done on that side, but I surely blame much more the OpenSSL developers.

      • dan@upvote.au
        link
        fedilink
        arrow-up
        5
        ·
        9 months ago

        OpenSSL did add to the entropy pool a bunch uninitialized memory and the PID.

        Did they have a comment above the code explaining why it was doing it that way? If not, I’d blame OpenSSL for it.

        The OpenSSL codebase has a bunch of issues, which is why somewhat-API-compatible forks like LibreSSL and BoringSSL exist.

        • suy
          link
          fedilink
          arrow-up
          1
          ·
          9 months ago

          I’d have to dig it, but I think it said that it added the PID and the uninitialized memory to add a bit more data to the entropy pool in a cheap way. I honestly don’t get how that additional data can be helpful. To me it’s the very opposite. The PID and the undefined memory are not as good quality as good randomness. So, even without Debian’s intervention, it was a bad idea. The undefined memory triggered valgrind, and after Debian’s patch, if it weren’t because of the PID, all keys would have been reduced to 0 randomness, which would have probably raised the alarm much sooner.

    • Socsa@sh.itjust.works
      link
      fedilink
      arrow-up
      2
      ·
      9 months ago

      This has always been the case. Maybe I work in a unique field but we spend a lot of time duplicating functionality from open source and not linking to it directly for specifically this reason, at least in some cases. It’s a good compromise between rolling your own software and doing a formal security audit. Plus you develop institutional knowledge for that area.

      And yes, we always contribute code back where we can.

      • datelmd5sum@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        9 months ago

        We run our forks not because of security, but because pretty much nothing seems to work for production use without some source code level mods.

    • fruitycoder@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      9 months ago

      There’s gotta be a better way to verify programs then just what the devs do. For example patching the fuzzer, that should be seen as a clear separation of duties problem.

      That constant issue of low Dev/high use dependencies is awful and no one I’ve met on the business end can seem to figure out that need to support those kind of people or accept, what should frankly be, legal liability for what goes wrong. This isn’t news its just a cover song. And its not an open source problem, its just a software problem. (