5 ms·
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
by homebrewer 1y 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 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 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 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/#minimumreleaseage https://docs.renovatebot.com/configuration-options/#minimumr...
https://docs.renovatebot.com/presets-default/#enablevulnerabilityalerts 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.
- garblegarble 1y agoBubblewrap 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 https://github.com/lynaghk/sandboxtron/tree/main
- simonw 1y agosandbox-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 1y agoAbsolutely 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 1y agoYes 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 1y agoYeah 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/main/sandbox/policy/mac https://chromium.googlesource.com/chromium/src/+/refs/heads/...