You've skipped a few steps, until you overthrow the government all you have a broken society with a system of governance that's deemed to be illegitimate, therefore its rules and actions are illegitimate.

If you want to tear up the constitution and implement a new system of governance with "less government" then you're effectively advocating for a revolution. Just be honest and don't try to sell this as an incremental policy change.

That's the constitutional bedrock of our societies. That doesn't mean it's always true but if you denounce that as a legitimate and achievable goal then you don't have a society anymore.

------

[Re: 3] https://github.com/patriksimek/vm2

> vm2 attempts to sandbox untrusted JavaScript code within the same Node.js process as your application. It does this through a complex network of Proxies that intercept and mediate every interaction between the sandbox and the host environment.

> JavaScript is an extraordinarily dynamic language. Objects can be accessed through prototype chains, constructors can be reached via error objects, symbols provide protocol hooks, and async execution creates timing windows. The sheer number of ways to traverse from one object to another in JavaScript makes building an airtight in-process sandbox extremely difficult.

[Re: 4] https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-m...

(Different person here) I don't have data and I don't think I need it. You either have a process to push security-critical updates out very rapidly or you don't.

If you have that process then nothing changes for you because that cooldown won't be used in that context.

If you don't have that process then nothing changes for you because you weren't pushing out those time-sensitive patches to begin with. But now you won't get hit by drive-by supply chain attacks.

The vast majority of "high severity vulnerabilities" in your dependencies are just noise by the virtue of not being exploitable in the manner that they're used in your project.

Bug? More code. Unexpected behavior - read the docs? Couldn't find anything. Let's try another 1000 lines of workarounds. Still doesn't work? Write another 1000 lines to monkey-patch behavior. It sort of works now.

The actual solution is removing those 2000 lines and passing the correct argument on line 25 which is clearly documented. Most humans would never do that because we're too lazy but it's so easy to generate slop at an exponential rate and blow up the LOC metrics.

1. Malware logs you out of github.com

2. It waits for you to navigate to the login page

3. It initiates an SSH/signing operation requiring physical touch

4. You hit login on github.com, a 2nd FIDO operation is queued up

5. You press the yubikey button, confirming the SSH operation

6. "Nothing happens", so you press it again to log in

7. You're now logged in, and your SSH credentials have just been hijacked.

Or it could just inject itself into your shell profile, and do this the next time you ssh anywhere. You never really know what you're confirming so Yubikey's threat model implicitly depends on the host device being trustworthy.

This is why hardware wallets for crypto have a physical display to confirm the address and the amount before signing the transaction.

You probably have the same logical type duplicated in 3+ different places (at least partially), including inline casts using type literals like "maybeCat as { meow(): void }"

https://eslint.org/docs/latest/rules/no-restricted-syntax

https://typescript-eslint.io/play/

What are the chances that your code is using a vulnerable dependency AND doing so in an exploitable manner AND the vulnerability being serious enough to warrant immediate attention? The likelihood of that is extremely low unless you're high-profile enough to have a team dedicated to this.

99.9% of vulnerabilities in your dependencies aren't actually exploitable in your project. Most exploitable vulnerabilities probably aren't that serious. And even if it's serious, it's unlikely that you would be targeted immediately.

On the other hand you have a constant stream of unreviewed dependency updates, each one having a small chance of containing malicious code.

The most pragmatic approach, IMO, is to set up alerts for high severity CVEs, cooldown of at least 24h, and only execute code in per-project sandboxes (VMs or containers).

1 day is short enough that it would practically never be a problem, regardless of severity. It's historically been long enough to discover the vast majority of these supply chain attacks, and alerting for high severity CVEs is something you should be doing anyway if you're worried about security.

    mkdir demo && cd demo
    npm install --save koa@3.2.0
    echo 'console.log("--- pwned by a transitive dependency ---")' >> node_modules/tsscmp/lib/index.js
    node -e "import 'koa'"

Either way it misses the point, nobody just fetches code and removing post-install scripts wouldn't change much because you're going to run `npm run something` 5 seconds after you run `npm install`.

It does not. Opening a project in an IDE has always been dangerous because there are about a thousand language server and analysis tools that run in the background. This is why IDEs ask you whether you trust the contents of a repository.

An even if some automated background execution initiated by the IDE doesn't get you, running `npm run test` 15 seconds later will.

This is semi-common and in no way unique to NPM.

Less: Do you want to run "npm run build"?

More: "npm run build" tried to read your Chrome cookie database, do you want to allow that?

Some agents like Codex use sandboxing on Linux/MacOS but the permissions are far too coarse - they'll run the command in a relatively strict sandbox and when it fails they'll ask you to allowlist the command as a whole, forever. There should be a new permission prompt every time a command tries to do something new.

Claude suggests (or used to suggest - it's been a while) to allowlist "bash" which completely defeats the point. If you do that the agent can run `bash -c "echo literally anything"`

npm run build = run an arbitrary shell command written in package.json

Meanwhile the agent could have done any of the following without approval:

- edited `package.json` to contain any arbitrary build command

- planted malicious code in `build.js` (called by `npm run build`)

- planted malicious code in `node_modules/xyz/index.js` (imported by `build.js`)

To illustrate: Because I wrote this comment, the sun is going to rise again tomorrow.

That's not a positive thing, good recipe developers are Rare. For every recipe that's been meticulously tested and documented there are 1000 that haven't been. Many cookbooks are riddled with errors.

I think 1 token/second is optimistic here - and even then it's over 11 days per million tokens.