Crates that don't publish the released source code

community
1

Most open source crates are hosted on Github or some similar site, and they publish their latest code there simultaneously when they publish it on crates.io. But fairly often I've seen users who publish a release on crates.io, but forget to push it to Github. Usually the unpushed commit simply increases the crate's version number and adds a tag. And usually the author quickly pushes it when I remind them. I've even forgotten to push such a commit myself once or twice. It's easy to forget to do it if there's an error during cargo release.

But what if the forgotten commits are more substantial? For example, the venerable hexdump crate never pushed release 0.1.1 to Github. The unpushed code not only incremented the version number, but added 62 new lines of code too. And since the crate has long since been abandoned by its author there's little prospect of that oversight being corrected.

Failing to push releases to github makes code harder to audit. Should this be considered a security risk? For that matter, is there any easy way to ensure that code which does get pushed to the public repository matches what gets published on crates.io ?

2

Here's a recent thread on the topic.

4 Likes
3

I don't think so. The source code published on crates.io is the only source of truth. Linking it to a tag or commit hash is nice and should be encouraged, but it's useful mostly only for browsing development history.

I long argued that it would nice for crates.io to allow browsing source code of published crates, but it's just a QoL feature, not a necessity for code audit.

6 Likes
4

I can't remember if it came up in the other thread, but a related point is that the history (and availability) of a repo can be changed, so any sort of sort of crates.io/repo sync check is a point-in-time check.

1 Like
5

docs.rs does support this fwiw.

3 Likes
6

e.g. using the mentioned crate, https://docs.rs/crate/hexdump/0.1.1/source/

This is always the exact contents uploaded for the packaged crates, and is available even if the documentation build fails. I believe the various tools for auditing dependencies also grab the packaged source tree and prompt you to review that source instead of relying on a git checkout.

(If there isn't already, it might be beneficial to set up an automated crev review source which provides a weak confidence review indicating whether the published package appears to match what's in the indicated source VCS repository. It's not a perfect indicator but it's at least a useful smoke test.)

1 Like
7

If so it should be coupled with checking for changes over time (as otherwise it's a free boost in score even if you rewrite history).

8

And don't forget to consider websites that return a different git repo depending on which ip address made the request to fool crates.io into thinking that the user would see the correct source.

9

Thus specifying the theoretical tool to provide weak review confidence. Essentially any metric can be gamed.

10

There's a catch: the source snapshot is taken after the build. Therefore it should not currently be trusted to be accurate in the case of any build-time malicious code execution (which could, at least in principle, hide itself by deleting its own files).

4 Likes
11

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.