rfcs
SES-shim
Our great sponsors
rfcs | SES-shim | |
---|---|---|
35 | 13 | |
713 | 730 | |
0.8% | 3.0% | |
5.6 | 9.9 | |
18 days ago | 6 days ago | |
JavaScript | JavaScript | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rfcs
-
Yarn 4.0
npm workspaces plus Wireit works far better than Lerna, in my experience.
https://github.com/google/wireit
Wireit's ability to specify actual script dependencies, do caching (and on Github actions), and it's long-running service script support make it much more useful and comprehensive than Lerna.
I agree that this should be built into npm. There's an RRFC for it here: https://github.com/npm/rfcs/issues/706
-
How do you know that the .exe or .apk file for an open source software on github is actually compiled from the viewable source code?
This just got accepted as a proposal in NPM: https://github.com/npm/rfcs/pull/626
-
Why aren't Node.js package managers interoperable?
npm also plans to support pnpm-style node_modules
-
Axios shipped a buggy version and it broke many productions apps. Let this be a lesson to pin your dependencies!
(I usually end up removing npm ci from CI/CD since I think it is way too slow and want to cache node_modules from previous builds; I'm waiting for https://github.com/npm/rfcs/issues/415 to land to make this fail-safe npm install --from-lockfile. Yarn does support this already)
- Lerna has gone. Which Monorepo is right for a Node.js BACKEND now?
-
How to respond to growing supply chain security risks?
I started following this problem from the discussion at npm about making install scripts opt-in. But install scripts are not the only threat, there are more ways for malicious actors:
-
On node-ipc and the importance of trusting trust
What I’m proposing is specifically in cases where sub-dependencies may have a known vulnerability but that isn’t in any of the call paths of your direct dependency. It’s an alternative to the “audit assertions”[1] proposal, which I find problematic for reasons I discussed there before I bowed out. My idea is that you can be confident you’re not affected by a vulnerability in a dependency (at any depth), if that vulnerability is no longer in the code in the first place.
It also reduces the surface area to vet in the first place. It’s highly likely many dependencies will be stripped down considerably, if not outright deduplicated or eliminated. The “npm installs thousands of dependencies” thing is a real problem, but it’s also partly because it’s installing stuff you’ll never actually execute in any way.
You can pare down sub-dependencies with confidence, because you already know what code paths are hit by the parent dependency at packaging time. You can’t do that with direct dependencies until you go to package/deploy, because of course you may expand your usage of their APIs during development.
-
On the Weaponisation of Open Source
https://github.com/npm/rfcs/issues/509
it more or less just makes it difficult for updates to propogate, which is arguably a good thing.
- BIG sabotage: Famous npm package (node-ipc) deletes files to protest Ukraine war
-
Pitfalls When Adding Turborepo To Your Project
Even if you run npm install, only npm 7 and up support workspaces. There is no straightforward way to enforce developer npm version although it is not impossible, so you might want to document the version requirement in your root README. A developer without npm 7+ will end up with unresolved modules in their editor.
SES-shim
-
Building an Extension System on the Web
There are other potential solutions I haven’t explored close enough (like Endo and SES), or completely omitted as they’re based on an imperfect blacklist-based approach to security (like sandboxed WebWorkers). However, the mentioned 4 solutions are the top contenders, at least in my mind.
-
Show HN: Run unsafe user generated JavaScript in the browser
Agoric moved forward and Realms gave way to SES
https://github.com/endojs/endo/tree/master/packages/ses
And Endo is a set of tools (being) built around it to make it more practical for particular usecases
There's a related proposal for Compartments and Module constructor is a prerequisite to that. A shim for the entire thing exists, with lockdown and Compartments isolating code:
https://github.com/endojs/endo/tree/master/packages/ses
https://github.com/tc39/proposal-compartments/
It has usage already, eg. metamask snaps
-
Deno 1.26
Yea you could restrict the app by whitelisting only the network services and folders that it will use and that's pretty valuable though at least on Linux could already easily be achieved otherwise. It's good that Deno makes it easy but let's be honest, most people will just pass -A.
I'd love to see a permissions system on a library basis. It would ask the first time a dependency is added and when a new permission is requested after an update. Javascript doesn't make that easy though by being so dynamic. SES could maybe help: https://github.com/endojs/endo/blob/master/packages/ses/READ...
-
Node runtime that sandboxes all NPM dependencies by default
I was poking around on the internet a bit earlier and I found this project. It looks pretty cool, and I figured perhaps a few of y'all might find it cool too!
I have no idea if it actually sandboxes networking by default. This other project, endo[0], seems to add some of that functionality.
Regardless of the maturity though, it makes me excited to see this type of work getting done now!
(What made me want to research it was this[1] thread from the other day.)
-
Open source maintainer pulls the plug on NPM packages colors and faker, now what
Fortunately the problem could become more tractable if something like SES / Endo takes off:
"Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies."
- Is metamask running on JavaScript?
- Embedded malware in RC (NPM package)
-
Researcher hacks over 35 tech firms in novel supply chain attack
Yeah. JavaScript is probably the closest to being there (with things like SES[0], LavaMoat[1], etc.) but we're not quite there yet. It's just shocking that this sort of thing is as seemingly obscure as it is; it's like the whole industry has collectively thrown up their hands and said code execution is unavoidably radioactively dangerous. (While simultaneously using package managers that... well.) But it doesn't have to be!
What are some alternatives?
vm2 - Advanced vm/sandbox for Node.js
pnpm - Fast, disk space efficient package manager
corepack - Zero-runtime-dependency package acting as bridge between Node projects and their package managers
Cargo - The Rust package manager
GHSA-g2q5-5433-rhrf
npm-workspaces-demo
feedback - Public feedback discussions for npm
node-ffi-napi - A foreign function interface (FFI) for Node.js, N-API style
coa - Command-Option-Argument: Get more from defining your command line interface
turborepo - Incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust – including Turborepo and Turbopack. [Moved to: https://github.com/vercel/turbo]
ua-parser-js - UAParser.js - Free & open-source JavaScript library to detect user's Browser, Engine, OS, CPU, and Device type/model. Runs either in browser (client-side) or node.js (server-side).
node-ipc - A nodejs module for local and remote Inter Process Communication (IPC), Neural Networking, and able to facilitate machine learning.