• magic_lobster_party@fedia.io
    link
    fedilink
    arrow-up
    36
    ·
    5 days ago

    it’s the kind of dependency developers install without a second thought

    I got a feeling this is an attack vector that will continue to grow, as now there’s vibe coding frameworks installing random dependencies without a thought at all.

    • corsicanguppy@lemmy.ca
      link
      fedilink
      English
      arrow-up
      9
      arrow-down
      1
      ·
      edit-2
      15 hours ago

      There’s two things at play, here:

      • installing dependencies without checking
      • a framework that will allow this

      Both are absolutely the fault of the user.

    • wildbus8979@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      14
      ·
      edit-2
      5 days ago

      This truly has grown past a JS problem. NPM was kind of the first time dependencies were installed by the project rather than through the OS. But nowadays this has become the norm, golang, rust, and to an extent python also work by installing dependies directly from git for the most part. This isn’t going to get any better unless we revert to OS based dependencies which noone wants to do because developers want the latest and greatest model.

      • rhabarba@feddit.org
        link
        fedilink
        English
        arrow-up
        2
        ·
        4 days ago

        This isn’t going to get any better unless we revert to OS based dependencies which noone wants to do because developers want the latest and greatest model.

        A few operating systems (e.g. OpenBSD) do actually (try to) enforce using pkg for Perl dependencies, due to Perl being “system Perl” instead of “packaged Perl”.

      • muusemuuse@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        4 days ago

        Can’t they make dependencies something that get checked at launch time? The executable says “I have the following external dependencies pulled in. “ and then if a version is blacklisted, the executable should stop and throw an error saying exactly what component was blacklisted and stopped it from running.

        Why can’t we have executable declare their dependencies at launch time to the OS?

        • wildbus8979@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          4 days ago

          That’s essentially how most distributions of Linux and Unix work. You package an app with a list of depencies like “libcaca >= 1.2.3” and that’s that. If that dependency isn’t available in the distro you need to have that packaged (and thus have a maintIner for said package) first. The distro’s package maintainers are responsible for keeping an eye on the upstream sources and provide reviews. Often there’s also a security team that watches for packages requiring expedited attention, and security backports.

          Then this sort of crap like NPM came along and it became popular for devs to package their own dependencies.

      • PushButton@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        4 days ago

        This isn’t going to get any better unless we revert to OS based dependencies which noone wants to do because developers want the latest and greatest model.

        Maven entered the room.

        • wildbus8979@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          2
          ·
          4 days ago

          I’m not super familiar with Maven so I could be wrong, but doesn’t Maven still pull depencies from upstream? That doesn’t fix the problem. Having depencies packaged in the OS means there is in theory some level of overview and review by the package maintainer(s).

          • PushButton@lemmy.world
            link
            fedilink
            English
            arrow-up
            4
            arrow-down
            1
            ·
            4 days ago

            There are two reasons. One is the name spacing that is inherent in Maven and bolted on to npm, and the enforcement or lack of enforcement in the repository. You can read more about that here https://blog.sonatype.com/why-namespacing-matters-in-public-open-source-repositories Then there’s the fact that npm runs “install” scripts when you download the component. This means if you can trick someone into grabbing your component by namespace confusion, typosquatting a name etc, you can get code run as soon as someone makes a mistake. Maven on the other hand only downloads the jars, it does not execute them. Taken together, you have an easier path to tricking people to grabbing your component with npm and that trick leads directly to code execution.

            —Brian Fox, Apache Maven PM & Sonatype cofounder & CTO

            I am on my phone, which is a bit too long to explain, but there are multiple facets to how NPM is worse than most packaging systems out there. There are enough on the web for you to browse and learn, if you are really interested to know more.

            But, here, I quoted a little something from Brian from Sonatype.

  • rollerbang@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    4 days ago

    I’ve got to research how can I do individual sandbox/jail for projects that are opened using VSC. Maybe dockerize everything 🤷‍♂️

  • iAmTheTot@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    5 days ago

    For a layman, how might one deduce if they were affected? I cannot really tell from the article if this was particularly widespread.

    • Deestan@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      5 days ago

      No way to know for sure based on this. If you used any app that “works with” WhatsApp in any way, you could be affected.