Support checksummed local registries for git sources

[snoopuppy582]

What does this PR try to resolve? Addresses #10939 and follows up on #11188. A git source can be replaced by a local registry, but Cargo.lock must continue to describe the original git source. Persisting the replacement checksum in the lockfile breaks the lockfile when source replacement is disabled. A same-version git revision update must also invalidate the extracted replacement source and its compiled artifact. This change keeps those responsibilities aligned: - replacement summaries expose the original source's checksum capability, so git lock entries remain checksumless; - local-registry extraction records the verified archive checksum in .cargo-ok and refreshes the source when that checksum changes; - replacement fingerprints include the original git revision, so same-version updates trigger recompilation. This is paired with dhovart/cargo-local-registry#289, which writes the SHA-256 of each generated git archive to the local-registry index. ### Prior concerns and how this PR addresses them The earlier discussion raised concerns beyond the initial checksum error: | Prior concern | Handling in this PR | | --- | --- | | Skipping an absent or empty checksum weakens corruption detection and couples Cargo to an external tool's sentinel value. | This PR does not add an empty-checksum exception. The paired cargo-local-registry change generates a SHA-256 for every git archive, and Cargo verifies that checksum before using or unpacking the archive. | | A replacement checksum describes the local archive, not the original git source. Persisting it in the git lock entry makes the same lockfile fail when source replacement is disabled. | ReplacedSource exposes the original source's checksum capability. It omits the replacement checksum from the mapped summary only when the original source does not support checksums, while retaining the replacement checksum for archive verification. Checksummed original sources keep their existing behavior. | | A same-version git update can leave the extracted local-registry source stale. | Local-registry .cargo-ok metadata records the checksum that was verified before extraction. A changed checksum clears and re-extracts that source directory instead of accepting the existing directory by name and version alone. | | Updating the git revision without changing the package version can leave compiled artifacts fresh against stale inputs. | The replaced-source fingerprint includes the original precise git fragment. Replaced packages whose original source is checksumless add that source fingerprint to the compiler fingerprint, so a new git revision triggers recompilation. | | Allowing arbitrary local-registry entries to mutate would weaken the normal registry immutability model. | This is not a generic checksum opt-out. Normal checksummed sources still retain lockfile checksums and mismatch enforcement. The additional compiler fingerprint is limited to source replacement whose original source is checksumless, and the replacement archive remains checksum-verified. | ### How to test and review this PR? The two new regressions cover both lockfile portability and same-version git updates: - git_dependency_can_be_replaced_with_checksummed_local_registry - updated_git_dependency_refreshes_local_registry_source_cache The main review points are that the lockfile retains the original source semantics, local archives remain checksum-verified, and ordinary registry replacements keep their existing behavior. Validated with: - cargo test --test testsuite local_registry:: (12 passed on current master) - adjacent registry, vendor, directory replacement, and source freshness tests - cargo test --lib (186 passed on current master) - cargo fmt --all --check - cargo clippy --workspace --all-targets --no-deps --keep-going - an end-to-end git revision update using the paired cargo-local-registry change

[Eh2406]

The issues you linked have a lot of technical discussion about the implications of different ways of doing the change and what their impacts. In order for a new PR to be accepted we would need a detailed summary of previous objections and technical concerns, with a description of how this PR addresses each one.

[snoopuppy582]

Thanks for pointing this out! I've updated the PR description to include a breakdown of the concerns raised in #10939, #11188, and #10071.

To give a quick overview, here are the main differences between this PR and #11188:

• There is no missing or empty checksum bypass. The companion cargo-local-registry change generates an archive SHA-256, which Cargo still verifies.
• The replacement checksum is used for archive verification, but it isn't written into a checksumless original git lock entry.
• The verified checksum is saved in the local-registry .cargo-ok metadata, ensuring that a changed archive gets re-extracted.
• The original precise git revision is included in the compiler fingerprint, so updating to a same-version revision will correctly trigger a recompile.

Just to clarify, normal checksummed sources still retain their lockfile checksums and mismatch enforcement, so this doesn't introduce a general mutable-registry mode.

I've also rebased onto the latest master (post source-tree move) and ran all the tests (local-registry, Cargo lib, rustfmt, and Clippy)—everything is passing green.

Let me know if there are any other previous concerns I should mention in the description, and I'd be happy to add them!

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @epage (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions and our LLM policy for more information.

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @epage, @weihanglo
• @epage, @weihanglo expanded to epage, weihanglo
• Random selection from epage, weihanglo