Remix.run Logo
homebrewer 3 days ago

Here's a short recap of what you can do right now, because changing the ecosystem will take years, even if "we" bother to try doing it.

1. Switch to pnpm, it's not only faster and more space efficient, but also disables post-install scripts by default. Very few packages actually need those to function, most use it for spam and analytics. When you install packages into the project for the first time, it tells you what post-install scripts were skipped, and tells you how to whitelist only those you need. In most projects I don't enable any, and everything works fine. The "worst" projects required allowing two scripts, out of a couple dozen or so.

They also added this recently, which lets you introduce delays for new versions when updating packages. Combined with `pnpm audit`, I think it can replace the last suggestion of setting up a helper dependency bot with zero reliance on additional services, commercial or not:

https://pnpm.io/settings#minimumreleaseage

2. If you're on Linux, wrap your package managers into bubblewrap, which is a lightweight sandbox that will block access to almost all of your system, including sensitive files like ~/.ssh, and prevent anything running under it from escalating privileges. It's used by flatpak and Steam. A fully working & slightly improved version was posted here:

https://news.ycombinator.com/item?id=45271988

I posted the original here, but it was somewhat broken because some flags were sorted incorrectly (mea culpa). I still prefer using a separate cache directory instead of sharing the "global" ~/.cache because sensitive information might also end up there.

https://news.ycombinator.com/item?id=45041798

3. Setup renovate or any similar bot to introduce artificial delays into your supply chain, but also to fast-track fixes for publicly known vulnerabilities. This suggestion caused some unhappiness in the previous discussion for some reason — I really don't care which service you're using, this is not an ad, just setup something to track your dependencies because you will forget it. You can fully self-host it, I don't use their commercial offering — never has, don't plan to.

https://docs.renovatebot.com/configuration-options/#minimumr...

https://docs.renovatebot.com/presets-default/#enablevulnerab...

4. For those truly paranoid or working on very juicy targets, you can always stick your work into a virtual machine, keeping secrets out of there, maybe with one virtual machine per project.

Hexshin0bi 2 days ago | parent | next [-]

"...but also disables post-install scripts by default."

in pnpm docs it says:

""" enablePrePostScripts Default: true Type: Boolean When true, pnpm will run any pre/post scripts automatically. So running pnpm foo will be like running pnpm prefoo && pnpm foo && pnpm postfoo. """

am i missing something here?

zkochan 2 days ago | parent [-]

enablePrePostScripts is about running "prebuild" and "postbuild" scripts automatically, when you run "pnpm run build"

zkochan 2 days ago | parent [-]

well, it is literally in an example in the text that you provided. So, I am not sure why you confused it with postinstall lifecycle scripts.

garblegarble 3 days ago | parent | prev | next [-]

Bubblewrap seems excellent for Linux uses - on macOS, it seems like sandbox-exec could do some (all?) of what bubblewrap does on Linux. There's no official documentation for SBPL, but there are examples, and I found sandboxtron[0] which was a helpful base for writing a policy to try to contain npm

0: https://github.com/lynaghk/sandboxtron/tree/main

simonw 3 days ago | parent [-]

sandbox-exec is so frustrating. It could be a genuinely excellent solution to a whole bunch of sandboxing problems, except...

1. Documentation is virtually nonexistent. I think that is inexcusable for a security tool!

2. The man page says that it's deprecated, and has done for around a decade. No news on when they will actually remove it, maybe they never will? Hard to recommend it with that axe hanging over it though.

garblegarble 3 days ago | parent [-]

Absolutely agreed on the lack of documentation, it seems completely insane (I assume this is because they want to reinforce that only Apple should be writing policies - but still no excuse for it)

>Hard to recommend it with that axe hanging over it though.

Given the alternative being no way to limit untrusted tooling at all today, it seems worthwhile using it despite these problems?

There's also a (very slim) chance that if it became central to the security of developers on macOS that Apple would give slightly more consideration to it

simonw 3 days ago | parent [-]

Yes definitely worth using it, but I don't know how much time I want to spend integrating it deeply into my own open source projects given its uncertain status.

garblegarble 3 days ago | parent [-]

Yeah I know what you mean... one positive is it looks like Google use it in Chromium[0], so at least Google think the API will stick around for a while (and provides a big platform Apple would break if they discontinued it)

0: https://chromium.googlesource.com/chromium/src/+/refs/heads/...

advocatemack 3 days ago | parent | prev | next [-]

You can also use tools like safe-chain which connects to malware databases and blocks installations of malicious packages. In this case it would have blocked installs around 20 minutes after the malware was added as this was how long it took to be added into the malware databases. https://www.npmjs.com/package/@aikidosec/safe-chain

pt 3 days ago | parent | prev | next [-]

When we close and reopen VSCode (and some other IDEs), it updates the NPM packages for the installed plugins. Would these mitigations steps (e.g. pnpm) also take care of that?

2 days ago | parent | prev | next [-]
[deleted]
rayhan0x01 2 days ago | parent | prev [-]

[dead]