| Yep, supply chain attacks are a near-universal problem with programing language package managers. I think there's a lot of room for improvement here. Some good low-hanging fruit IMO would be to: 1. Take steps to make package source code easier to review. 1.1. When applicable, encourage verified builds to ensure package source matches the uploaded package. 1.2. Display the source code on the package manager website, and display a warning next to any links to external source repositories when it can't be verified that the package's source matches what's in that repo. 1.3. Build systems for crowdsourcing review of package source code. Even if I don't trust the package author, if someone I _do_ trust has already reviewed the code then it's probably okay to install. 2. Make package managers expose more information about who exactly you're trusting when you choose to install a particular package. 2.1. List any new authors you're adding to your dependency chain when you install a package. 2.2. Warn when package ownership changes (e.g. new version is signed by a different author than the old one). Long-term, maybe some kind of sandbox for dependencies could make sense. Lots of dependencies don't need disk or network access. Denying them that would certainly limit the amount of damage they can do if they are compromised, provided the host language makes that level of isolation feasible. |
> Long-term, maybe some kind of sandbox for dependencies could make sense. Lots of dependencies don't need disk or network access.
Just like with Android permissions, we could audit the crate sources to list out what functions it uses (out of the standard library or where ever) and provide an indication of that this particular crate is capable of.