Lib.rs version pages now link to git commits

When you publish a crate, Cargo makes a note of its git repository commit hash and includes it in the crates-io crate tarball. Now lib.rs exposes this information!

lib-dot-rs-version-links

Crates that don't have a repository link or were published before 2018 will fall back to source code view on docs.rs. It doesn't use git tags, so hopefully people stop asking me to tag my releases! :wink:

Note that this information can be trivially spoofed. There is absolutely no guarantee that the code uploaded to crates.io is related to the code in the git repository. If you want to see the actual source of the crate for security purposes, use tools like cargo crev open.

20 Likes

Sorry for the tangent, but coming from npm I'm surprised something like cargo release isn't built in.

cargo publish does everything it needs, and "tags" releases on crates-io, using its own protocol. It's not dependent on git on purpose. AFAIK npm works the same way, and doesn't modify git repositories either.

1 Like

BTW, I've also recently improved data collection for minimum supported Rust versions of all crates. The 2021 edition is taking over: it's required by 20% of all crates, and about 75% of actively maintained ones.

10 Likes

I must have misread that description, sorry!

Npm cli will git tag on npm version VERSION, and yarn does that and will also automatically version before publish. There's also a billion monorepo packages for keeping track of versions that try to handle git tagging...

It's a hard problem to automate correctly (eg publishing on a branch), and git tagging that isn't automated is pretty lame - so thanks for this anyway!

This little note at the bottom of the versions page caught my eye :eyes:

Minimum Supported Rust Version (MSRV) is only approximate. A range of two versions means "oldest rustc verified to work ~ oldest rustc that might work". Actual MSRV will vary depending on crate features, target platform, and dependency versions. The data is estimated based on the latest stable Rust version available at the time the crate has been published and cargo check on Linux/x86-64.

Does that mean lib.rs tries to figure out the MSRV (e.g. by running cargo check with each version of the Rust compiler) for any versions without a rust-version in their Cargo.toml?

A note to that effect seems worth adding to the note at the bottom of the page about MSRV calculation (and/or behind a ":warning:" or ":information_source:" button near the "[git]" links, or just in a title tooltip on the "[git]" links themselves).

The source code in Docs.rs is the same as that published to Crates.io, though, right?

Bottom of the page seems good for blanket disclaimers, I'd reserve a :warning: for when a mismatch has been verified by a future feature.

Yes. The server is sometimes slow, because I'm compiling almost every crate with almost every Rust version :slight_smile:

Here's my secret MSRV data view: https://lib.rs/compat/tokio

9 Likes

Is that something you could verify? Perhaps on the same infra as your MSRV testing, you could checkout the git commit, find the particular crate and cargo package it, and compare to the official package. Differences could be flagged for manual review, since there will surely be some false hits, but overall this could be a great indicator that something potentially shady is happening.

4 Likes

I would have said that comparing the Git and Crates.io versions of the source code of every crate seems like too much to ask of Lib.rs, but I guess it's not much compared to compiling all those crates with all those different rustcs.

Yes, I plan to do that. I'm not sure how to expose this information in a non-FUD way. A difference is not necessarily a sign of anything nefarious. For example, crates may include pre-generated files in the tarball to avoid having to run build.rs.

4 Likes

My guess would be that the least scary way to say there's a difference would be to show users the diff (behind "[see diff]", e.g.), so they can see that it's harmless (or not[1]).


  1. To be clear, I don't mean that I expect most users to be able to see that the diff isn't harmless if it isn't harmless. ↩ī¸Ž