Deterministic compilation is the best way to let people validate what they are downloading from repositories is what is in the codebases.
- files not being tracked in the repo
- files being part of the repo not being part of the published crate
- publishing with allow dirty from a local copy of the repo with changes that haven't been committed
- publishing from a commit that hasn't been pushed
I'm sure there are more.
It definitely does contain generated files, at least one crate has Rust code generated by a Python script that is not in the crate, only in the upstream Git repository.
"the best way"? Please make the argument for why. To do it properly, you must steel-man the alternatives (not shoot down straw-men)
If you introduce a backdoor into the compilation step, you run a much greater risk of detection. As long as there are multiple machines compiling packages and verifying whether the checksums match, any single backdoored machine will immediately be caught. This is much more important for package managers that do their own builds and ship their own binaries than for those who just ship whatever they got from the developer.
Without deterministic compilation, two builds of the exact same code might differ. This makes backdoors very hard to detect unless you have prior suspicion that one is present in a particular program.
Deterministic compilation forces people to embed backdoors directly in the source code repository, which creates an audit trail, is very visible in diffs, much easier to catch in reviews and so on. You can still get away with it (see the XZ situation), but it requires far more work.
It is important to remember that crates.io doesn't store binaries.
Prove me wrong! I'm open to it.
Or be that person who is too lazy to respond with an actual comment, downvotes, and probably assumes they are right.