[selfmodruntime]

Good answer. Here is one more, and I got to say I am really unsure why it isn't done this way: Check each update to a crate for the usage of a TCP / HTTP / UDP stack usage. There is absolutely no reason a crate for math (for example) should be introducing any of that in its code. If you catch something like this, you can be 99% sure it's malware.

Or even better, make crates request permissions for what kind of functions they can call, similar to the chrome plugin API. A graph crate doesn't need encryption, file opening or netstack permissions.

[echelon]

Transitive crate "permissions" would be amazing. To know at a glance if a crate does networking, filesystem access, IO, etc.

Someone could always roll their own IO, but self reporting and automated detection tooling (to catch those that slip through the cracks) would bring this percentage way down.

Maybe the language could even evolve "unsafe" for IO, even if just as a flag for users. That way it would all be incredibly easy to audit.

[ashishbijlani]

Packj tool (https://github.com/ossillate-inc/packj) analyzes Python/NPM packages for risky code and attributes such as Network/File permissions expired email domains. It uses static code analysis. We are adding support for Rust. We found a bunch of malicious packages on PyPI using the tool, which have now been taken down: examples https://packj.dev/malware [disclosure: I’m one of the developers]