-
Notifications
You must be signed in to change notification settings - Fork 2.6k
git dependencies in a local-registry require a non-existent checksum #10939
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Sorry for replying this thread late. I am not sure whether we can simply skip the checksum verification. From my understanding, the present of checksums is for basic filesystem corruption detection. It would be robust as before if we can keep this mechanism intact. In addition, Cargo knows nothing about the original source of a package from a local registry. Skipping checksum verifications sounds like leaking the details behind the local registry implementation (both in Cargo and Personally, I lean toward generating a checksum from Edited: mentioned |
Using cargo/src/cargo/sources/directory.rs Lines 147 to 151 in a3e352e
We could conditionally skip the check by changing the condition to something like: actual != checksum && !checksum.is_empty() If skipping the check is not an option, generating a checksum from cargo-local-registry is entirely possible, but attempting to update the registry causes cargo's resolver to fail with the following error (package name and url changed for anonymity):
As far as I can tell, in order to avoid this error, Cargo would need to generate checksums for all git sources, which would presumably be a big breaking change as similar errors would be observed on any crates with git dependencies. |
Totally valid. When a lockfile already lacks checksums for git dependencies, the only possible way to get around is indeed skipping that check. Cargo doesn't even require a package checksum for a git dependency to validate the integrity. I am fine with the solution you propose. Thank you for the well-written explanation! Would you mind sending a pull request for this patch? |
Sure. I've made the changes locally. I'll just tidy up the test I've added for this and create a PR later today. |
Hi @weihanglo @jarhodes314 are there any other alternatives for getting this to work ? |
@mehulmathur001 As far as I understand, you could do this to bypass some checks: echo '{"package":null,"files":{}}' > $some-crate/.cargo-checksum.json |
Problem
Ordinarily cargo doesn't require checksums to be present for git dependencies, and therefore it does not include a checksum in the lockfile for any git dependencies. If, however, the git dependency is vendored in a local registry (e.g. with
cargo local-registry
), cargo verifies the checksum when unpacking the crate, due tocargo/src/cargo/sources/registry/local.rs
Lines 131 to 134 in 5ac9be2
I've attempted to work around this by adding any missing checksums to the index of the local registry after generating/updating the local registry. This does allow my crate to compile, but I can then no longer update the registry as the checksums cargo has added to the lockfile are no longer expected when source replacement is disabled since git dependencies do not really have a checksum.
It appears to me that the checksum should just not be verified in cases where it is not present in the index.
Steps
libc = { git = "https://github.com/rust-lang/libc" }
cargo install cargo-local-registry --version 0.2.2
cargo local-registry -s Cargo.lock registry
.cargo/config.toml
in the current directory with the following contents:cargo build
and observe that libc cannot be found in the local registry (to ensure the local-registry is correctly configured).cargo local-registry -s Cargo.lock registry --git
to create a local registry including git dependencies.cargo build
again and observe the "failed to verify checksum" error.Possible Solution(s)
Where a checksum does not exist, for a package in a local registry, cargo should not attempt to verify it.
Notes
No response
Version
The text was updated successfully, but these errors were encountered: