In recent years it became popular in programming language communities to share large amount of code using various package managers. Rust is no exception, it is very easy to share your own code and use code written by others by using Cargo. At first sight, this seems to be a good thing. As time passes, more and more package will be available, eventually providing everything that someone may need in an every day software project. However, as shown by the community of Node.js, this solution is hardly perfect. If an average software depends on thousands of 3rd party packages, auditing and trusting the software becomes a very tricky problem.
Due to the amount of code to be verified and the speed of development, manually auditing hundreds or thousands of packages on every update is simply not feasible. I believe this issue needs tooling support.
I propose the creation of a tool that processes a library crate and generates the following meta data:
- list of all modules/functions used from Rust standard library by the given crate
- list of all extern function calls (all “C” functions)
- list of all dependent crates and functions called from the dependencies of the given crate
- whether the crate uses unsafe blocks
- whether the crate is using a build script
This list becomes the list of capabilities needed to execute the code of the given crate. The list could also be available for each version on crates.io.
Every time someone compiles a rust crate, the user can save the full capability requirements of all dependencies. This list can be used to verify/check that after updating a set of dependencies, no new capability is required for any of them. I.e. a seemingly innocent base64 encoder is not sending all data to a shady webserver.
If we squint hard enough, this problem is analogous to trusting a mobile application on your mobile phone. A mobile application is not supposed to be able to do everything it wants to, the user can check the list of permissions required for that app before installing the application. Later when the application is updated, the user is given a chance to accept/block the changes in permissions. I believe something similar must be done for crates.
It is important to guarantee that if this tool is not complaining about a dependency update then that update must be perfectly safe (or at least as safe as the previous one?). If the tool is complaining, the user’s responsibility to check/verify the update and accept it.
Is this idea viable?
I intentionally ignored the safety of build scripts (i.e. will the build script steal my data?). I believe the trusting issue of build scripts is even more complicated and cannot be solved using this mechanism.
Some of the related discussions: