I'm a little confused on the proposed logistics here. Assume that "cargo publish" did the above describe validation. What would happen in the following scenario:
I, a malicious crate publisher, insert some malicious code into my crate. I commit the malicious code via mercurial/pijul/git/whatever. Due to the aforementioned validation, I'm required to push this code to some public repo before publishing. I do that. (I assume I also have to record the name of a version control reference in my cargo.toml file. For example, the name of a git tag). Then I run
Crates.io on the backend will validate that the publicly available code matches what is uploaded in the .crate file (taking into account the differences described by pietroalbini).
But after that validation happens, I immediately delete the commit/tag that I just published, and perhaps publish a new one in its place (one that doesn't have the malicious code).
What happens now? Anyone can still download the crate file to inspect the code (edit: but the initial code verification is now useless). Will there be additional tools that will allow a downstream user of this malicious crate to say "the code uploaded at package time used to match some public commit, but not that commit cannot be found"? This is too expensive to do everytime a crate is downloaded. Maybe cargo-crev could learn to do this?
FWIW, I am somewhat skeptical of this code-comparison approach, and I also think that 2FA or something similar is the better approach to protect against the misuse of compromised crates.io credentials