Rust Programming

8183 readers

36 users here now

founded 5 years ago

MODERATORS

[email protected]

cargo-goggles: verify that crates.io releases can be reproduced from the git repository (crates.io)

submitted 7 months ago by [email protected] to c/[email protected]

5 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] Vorpal 8 points 7 months ago (4 children)

Due to the recent xz trouble I presume? Good idea, I was thinking about this on an ecosystem wise scale (e.g. all of crates.io or all of a Linux distro) which is a much harder problem to solve.

Not sure if the tag logic is needed though. I thought cargo embedded the commit ID in the published package?

Also I'm amazed that the name cargo-goggles was available.

[–] [email protected] 4 points 7 months ago (3 children)

Correct. To be clear, the xz vulnerability shows that this is just a very small step, but it will at least make git repo audits more useful since you will then know that the crates.io release matches.

Unfortunately, the git commit isn't always available, either because of releases made with old versions of cargo, or because maintainers deliberately publish with cargo publish --allow-dirty or cargo hack --no-dev-deps

[–] Vorpal 3 points 7 months ago (1 children)

Yes, obviously there are more ways to hide malicious code.

As for the git commit ID, I didn't see you using it even when it was available though? But perhaps that could be a weakness, if the commit ID used does not match the tag in the repo, that would be a red flag too. That could be worth checking.

[–] [email protected] 2 points 7 months ago (1 children)

I'm not completely sure what to do here because many crates seem to get published from the release PR branch, not the main one, so the commit id is usually unreliable anyway.

On one side I want something strict that can't be easily bypassed, on the other if everything's a red flag you'll just ignore it

[–] Vorpal 2 points 7 months ago* (last edited 7 months ago)

Hm, that is a fair point. Perhaps it would make sense to produce a table of checks: indicate which checks each dependency fails/passes, and then colour code them with severity.

Some experimentation on real world code is probably needed. I plan to try this tool on my own projects soon (after I manually verified that your crate match your git code (hah! Bootstrap problem), I already reviewed your code on github and it seemed to do what it claims).

load more comments (1 replies)