You’re right about attackers being able to change runtime code.

pnpm does have some other features to prevent supply chain attacks, so there is still something to learn from other ecosystems. For example pnpm has a cooldown period for new dependencies and can prevent trust policy downgrades (eg new version published without build provenance where older versions did have it). See https://pnpm.io/supply-chain-security

Disallow lists are ineffective - better to disallow by default and require opt in.

Also, crates.io can defer serving up newly uploaded scripts that have a new build.rs / proc-macro dependency and warn publicly that a version introduces it.

Restricting build scripts 100% will help mitigate the impact, just not if you only deny it once. And they can develop other things like sandboxing for build scripts by default and escaping that to be the exception that has to be explicitly allowed.

The problem is that build scripts run automatically without user consent or intevention.

`cargo add` is sufficient to compromise you, before you have a chance to even vet the code.