Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
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.
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/
Small plug for LavaMoat (https://github.com/LavaMoat/LavaMoat) which includes tools to more granularly disable dependency lifecycle scripts via @lavamoat/allow-scripts.
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 (related to NVIDIA hybrid graphics offload):
https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commi...
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...
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
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 ...
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/