$ sudo rm -rf / === NPM install

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • OPS - Build and Run Open Source Unikernels
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
  • Cargo

    The Rust package manager

    Rust's Cargo seems to suffer from the same. And the tooling to avoid the wild "grab things from the Internet" route is quite lacking (shameless plug for attention: https://github.com/rust-lang/cargo/issues/10045).

    I don't have a problem with making the convenient route possible, but it's very troubling that the tooling actively fights you if you want to take a saner approach.

  • tmate

    Instant Terminal Sharing

    Some of this is solved with locked dependencies and an understanding of how "npm install" actually works, but I find this point really takes away any credibility for this article:

    > This is just one of the reasons why I think by 2023 working with ephemeral cloud-based dev environments will be the standard. Just like CI/CD is today.

    Over my dead body will I ever use a cloud environment to write code. tmate[0] might be the closest I ever get.

    I get some developers don't care about what they throw aimlessly onto a cloud, but I don't know what's being logged, what's being stored, how long it's being stored, who has access to it, what third-parties have access to it, and so on. The business I own or the one I write code for might care if those files were exposed like that.

    Use a local VM. Or a development proxy. The cloud isn't a solution for everything.

    [0] https://tmate.io/

  • OPS

    OPS - Build and Run Open Source Unikernels. Quickly and easily build and deploy open source unikernels in tens of seconds. Deploy in any language to any cloud.

  • LavaMoat

    tools for sandboxing your dependency graph

    Small plug for LavaMoat (https://github.com/LavaMoat/LavaMoat) which includes tools to more granularly disable dependency lifecycle scripts via @lavamoat/allow-scripts.

  • trash-cli

    Move files and folders to the trash (by sindresorhus)

    I believe Apple forked rm to provide protection for this case?

    Also, if you're willing to lean into npm a bit, there's tools that give a layer of protection over rm such as https://github.com/sindresorhus/trash-cli

  • bumblebee-Old-and-abbandoned

    OUTDATED!!!!! - Replaced by "The Bumblebee Project" and "Ironhide"

    Bumblebee (related to NVIDIA hybrid graphics offload):


    There so many comments on that commit that Microsoft Github's backend apparently cannot load the page -- I just get the "unicorn".

    Anyway, this issue also points it out: https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

  • ego

    Alter Ego: run Linux desktop applications under a different local user (by intgr)

    I haven't tried it yet, but Ego [1] feels like an imperfect but good enough solution to run your dev environment.

    [1] https://github.com/intgr/ego

  • rfcs

    Public change requests/proposals & ideation (by npm)

    Re https://github.com/npm/rfcs/pull/488. Thank you for your service! I had this on my TODO for months. Actually I just use yarn now where ever possible and set `enableScripts: false` both globally and per package. Doesn't solve all of the npm ecosystem's sec issues (like allowing downloading binary blobs and other assets from arbitrary URLs, no cleaning on permission bits on archives, not blacklisting certain typo-esque package names, ...) but it's clear low hanging fruit and the push-back from maintainers is really crazy ...

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • tldr

    📚 Collaborative cheatsheets for console commands

    They're really quite different in my experience, but the difference is not one of availability so much as it is Python developers following traditional software engineering best practices. I write almost all my hobby projects in Python. Very rarely do I incur a dependency tree involving more than 5 or 6 projects while doing so.

    The rm -rf vulnerability is essentially a problem with a chain only being as strong as its weakest link. If any of the maintainers in the hundreds of node dependencies your project uses is malevolent, you're screwed. Hence, the security of the chain depends much more on the number of links it has rather than its innate strength.

    Even large and complex dependencies tend to be well engineered in Python. BeautifulSoup is a widely used library for loosely parsing HTML. It requires only Python and an internal library. lxml is another HTML parser (which BS can optionally use), and it requires only Python and a couple of C libraries. Even an entire web framework (Flask) uses only 4 Python dependencies directly and only one of these (the Jinja template engine) has recursive dependencies on other Python packages. All told it's about 10 Python packages needed in total.

    Or consider this, if you want an example of a trivial command line tool. The Python tldr[1] client uses only 3 libraries as recursive dependencies. The Rust client, tealdeer, has 119. The official nodejs client has, if I'm counting correctly, 603.

    [1] https://tldr.sh/

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts