The Crate Is the Artifact: crates.io Opens Rust’s Published Source to Audit
A new crates.io Code tab lets developers inspect the exact files Cargo downloads, moving dependency review closer to the published artifact itself.

Rust dependency review has gained a more concrete target: the package that Cargo actually downloads.
In its July 13 development update, the crates.io team announced a Code tab for crate pages. It lets developers browse the contents of published versions directly on crates.io, including normalized Cargo.toml files generated during packaging. That matters because the published archive can differ from the repository linked on a crate’s page.
The viewer is designed for audit work. It provides a file tree, search, syntax highlighting, and shareable line links. crates.io also repackages each published .crate archive into a seekable ZIP with a JSON manifest, allowing the interface to load individual files through HTTP range requests. The team says existing versions were backfilled, so the feature is useful for older dependencies as well.
This changes the practical question developers should ask during review. Instead of checking only the GitHub repository, teams can inspect the versioned package that enters their build: its generated manifest, included files, build scripts, and any assets that packaging rules admitted.
Cargo’s publishing documentation explains why this distinction exists. cargo publish compresses a package into a .crate file, rewrites and normalizes parts of the manifest, applies include and exclude rules, and verifies the extracted package. The resulting archive—not the repository checkout—is what a registry distributes to consumers.
A useful workflow is now straightforward: open the exact crate version on crates.io, inspect its Code tab, compare the packaged files with the repository and the output of cargo package --list, then review changes before upgrading. This is especially valuable for build scripts, generated code, bundled data, and workspace metadata that may be easy to overlook in a source repository.
The important caveat is that the Code tab is an inspection surface, not a complete provenance system. It shows the published artifact and can reveal differences from the linked repository, but it does not by itself prove that the archive was produced from a particular commit. Teams with stronger supply-chain requirements should continue recording checksums, reviewing lockfiles, and validating their build and release process.
The crates.io team says a version-to-version diff viewer is also in development. If delivered, that would turn the registry from a place to discover dependencies into a place to review the precise source changes that consumers receive.
Get the wire in your inbox
Every new signal, straight from the generator. No noise, unsubscribe anytime.


