> it’s got me nervous to use Python or Node.js these days
replyMy feelings precisely. Min package age (supported in uv and all JS package managers) is nice but I still feel extremely hesitant to upgrade my deps or start a new project at the moment.
I don’t think this is going to stabilize any time soon, so figuring out how to handle potentially compromised deps is something we will all need to think about.
NPM only gained minimum package age in February of this year, and still doesn't support package exclusions for internal packages.
replyhttps://github.com/npm/cli/pull/8965
https://github.com/npm/cli/issues/8994
Its good that that they finally got there but....
I would be avoiding npm itself on principle in the JS ecosystem. Use a package manager that has a history of actually caring about these issues in a timely manner.
It almost doesn't matter, because you can get pwned by a transitive dependency. If someone doesn't have the same scruples as you have, you're still at risk.
replyminimumReleaseAge and lockfiles also pin down transitive dependencies.
replyPNPM makes you approve postinstall scripts instead of running them by default, which helps a lot. Whenever I see a prompt to run a postinstall script, unless I know the package normally has one & what it does, I go look it up before approving it.
reply(Of course I could still get bitten if one of the packages I trust has its postinstall script replaced.)
How does this stance work with your CICD?
replyI suppose you would have to commit your node_modules, or otherwise cache your setup so that all prerequesite modules are built and ready to install without running post-install scripts?
replyMore like the Trivy incident (which led to the compromise of LiteLLM).
replyThere are ways to limit the blast radius, like running them in ephemeral rootless containers with only the project files mounted.
reply