Skip to content

Conversation

@paolobarbolini
Copy link

@paolobarbolini paolobarbolini commented May 23, 2025

This PR proposes reintroducing Cargo.lock into the repository.

I’ve read the rationale for removing it in taiki-e/cargo-llvm-cov#152, but I believe the situation has evolved and that the original concerns no longer outweigh the practical and security-related benefits of committing it:

  • After the XZ Utils incident, it became clear that the contents of the git repository must be the authoritative source of truth for a project, not secondary generated artifacts (including crates.io).
  • crates.io releases sometimes are missing some of the components required for running tests, so they cannot be used anyways. Some crates require tests to run in a git checkout, require heavy artifacts that weren't included in the crates.io release or git dev-dependencies (like in this case).
  • As the maintainer of the cargo-hack package in Alpine Linux, I find it very annoying to have to deal with the non-standard extra step of having to somehow generate the Cargo.lock myself in order to have the build be reproducible (which I do by downloading the crates.io tarball, extracting Cargo.lock, adding the test-helper dev dependency, running cargo to make it add it to the locked dependencies, and committing the final Cargo.lock into the aports repo 1). This workaround undermines the otherwise smooth and reliable packaging and ease of installation experience that Rust projects are known for. For other less attentive distros, which somehow fail to notice that dependencies are not locked, this makes the build non-reproducible.
  • As mentioned in the previous point, the Cargo.lock included in the crates.io release is incomplete, as it's missing the test-helper dev-dependency, so it cannot even be taken as-is if the build needs dev-dependencies (for example for running tests).
  • cargo install --git, which may come necessary in some cases (like installing the latest revision), doesn't use locked dependencies.
  • I don't like Dependabot, but I don't think it needs to be used here. Locked dependencies could be updated before each new release.

Footnotes

  1. example https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/84637

Copy link

@joshka joshka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to this
More advice straight from the cargo book that backs this up:
https://doc.rust-lang.org/cargo/faq.html#why-have-cargolock-in-version-control

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants