• Danterious@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    30
    arrow-down
    1
    ·
    8 months ago

    Semi related to this I think a good way to avoid back doors in open source software is to have as few dependencies as possible. So I appreciate that this is a thing.

    • taladar@sh.itjust.works
      link
      fedilink
      arrow-up
      16
      ·
      8 months ago

      Maybe it avoids backdoors but it also avoids the maturity and security of using shared implementations for common tasks in favour of half-assed implementations in your own code.

      • Phen@lemmy.eco.br
        link
        fedilink
        arrow-up
        11
        ·
        8 months ago

        Speaking specifically about npm: A ton of packages used as dependencies for a million different things have very loose quality control, some even merge community PRs straight to release without checking the code in any way. More often than not I have run into packages maintained by people with no connection to the original dev and don’t even know how its code actually works.

        I remember a couple years ago I needed to read zip64 files so I picked up the zip file definition and implemented the read operation for it in the package we were using for zips. I only implemented a very small subset of the format to strictly solve my problem. I opened a pr to them saying “here’s some quickstart of you plan to add full support for zip64” - next time I checked they has merged my pr as if was and now were having folks registering issues for incomplete zip64 support.

        • taladar@sh.itjust.works
          link
          fedilink
          arrow-up
          2
          arrow-down
          2
          ·
          8 months ago

          And you think the same language ecosystem that produces those results will suddenly produce better ones when the same code is inlined, probably as a copy of some Stackoverflow code or potentially code they found on GitHub in some random fork of some other repository?

          • Phen@lemmy.eco.br
            link
            fedilink
            arrow-up
            2
            arrow-down
            1
            ·
            8 months ago

            Yes, I trust my coworkers and our company’s workflow enough to produce better code than that.

      • Name-Not-Applicable@kbin.social
        link
        fedilink
        arrow-up
        2
        ·
        8 months ago

        Just because someone else wrote it, doesn’t mean it’s a good implementation, or worth bringing its pile or dependencies into your project.

        • taladar@sh.itjust.works
          link
          fedilink
          arrow-up
          3
          ·
          8 months ago

          True, but the opposite is true too, just because you or one of your team members wrote it that doesn’t mean it is a good implementation. Especially considering your team can not have domain experts on everything. There is reason the rule is “never roll your own crypto” and not “crypto is security relevant, always roll your own”.