This used to be more common but the pattern these days is to have the binaries split into optionalDependencies which declare their supported CPU etc, one per supported platform. Then npm will install just the matching one (optionalDependencies that require a different platform aren't installed).
The fact that most of the ecosystem has moved to this pattern is a big part of why this change is now feasible.
They have taken action as of very recently. The latest version [1] of npm warns when there are install scripts and tells you they will be disabled by default in a future version, with a per-dependency opt in mechanism [2].
I have; you specify one optional dependency per platform and set the requirements in each package. It works fine. A bunch of packages do this (e.g. esbuild). I don't know what your complaint is or what you're asking for.
> most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages
Technically true, but wheels can include a `.pth` which will run arbitrary code as soon as Python is started, which is only marginally less dangerous. Recently exploited in the LiteLLM attack.
That appears to be an exploitable feature of the language, not the package manager per se.
We could then add the philosophical question of asking what's the difference between:
1. Adding malicious code to a package's .pth file that's evaluated automatically on every python invocation
2. Adding malicious code to the package itself that's evaluated automatically on every python invocation _that uses that package_
Packaging systems that don't run arbitrary code when you install a package are more trustworthy than ones that do, but there's still the essential trust you have to place in all code you're installing, directly and indirectly.
These things are usually caught by tools specifically scanning npm or by the maintainers noticing their account is compromised, not by people auditing their own installed packages.
2fa being enabled for people on the team is different from 2fa being required for publishing. It is not current possible to enforce (or use) 2fa for publishing with trusted publishing.
> type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to still have interpreted code at the end)
All major server-side JS runtimes are capable of executing TypeScript without transpilation these days. Complex build processes are only really a thing for client-side JS. The normal state of affairs these days is to run server-side code with no build step whatsoever.
That's true to some extent, but working with many modern frameworks often still requires a build step. Next.js in particular has quite a heavy toolchain.
Ehhhhh basically none of those exploits generalize beyond one very specific engine and set of conditions, and half of them are things to do with interactions between JIT tiers and can't be reliably triggered.
Browsers have said that they are unwilling to ship any new cancelation mechanisms given that AbortSignal already exists, so we can't ship a different CancelToken. But I think there's a path to standardizing a subset of the existing AbortSignal machinery [1].
(I am on TC39 and while this isn't my highest priority I did bring the topic for discussion at the last meeting [2], and there was support from the rest of committee.)
Yes, I was around during the original discussions. AbortSignal exists because TC39 was taking too long and cancelling fetch() is table stakes for a networking oriented platform like the web.
Those threads are a good example of what's wrong in TC39. A simple AbortSignal could have been added, but by the time it's reconciled with SES, large speculative APIs like Governers, or the original attempt to add a parallel throw mechanism just for cancellation, nothing actually gets done.
It's been 10 years since CancelToken was first discussed and we're still debating it.
I agree that the original cancellation discussion was bad. I don't agree that these threads reflect the same disfunction. They're a new effort (from me). No one was working on it previously because browsers have said that they were unwilling to add any other form of cancellation given that AbortSignal already exists, so there was never a chance to add a separate CancelToken once it shipped. The work to be done now is basically administrative: moving a subset from the WHATWG spec to TC39. This has ~no relevance to user's lives unless they're using a JS runtime which does not implement the WinterTC spec, which is approximately no one. The delay has nothing to do with SES (which has no bearing on this), and Governors are a _use case_ which motivates bringing it into the language, not a thing with which it needs to be reconciled.
The fact that most of the ecosystem has moved to this pattern is a big part of why this change is now feasible.
reply