Downstream evidence: polymorph-components/polymorph-webcrypto#312 (item 3), which this issue extracts so it can be tracked where the fix lives.
#44 ruled that artifact_sha256 is provenance, not identity: lock --check ignores it. But lock-update still rewrites the field with a machine-dependent value — rustc embeds absolute paths, so a guest built from a git/registry dependency (or any out-of-workspace path) hashes differently per machine — and every lock regeneration on any machine therefore carries a meaningless hash-line diff, even when the case inventory is unchanged.
Observed repeatedly downstream, where "the diff is the review surface" is the lockfile's whole point:
- polymorph-webcrypto #324/#325: near-identical lockfiles differing only in the hash line.
- polymorph-webcrypto #353 (229dae5): a census-driven
lock-update churned artifact_sha256 again, unrelated to the change under review.
Options, in rough preference order from the downstream perspective:
- Teach
lock-update to preserve the committed artifact_sha256 when the case inventory is unchanged (diff appears only when something identity-relevant moved).
- Stop emitting the field entirely (provenance could move to a side channel or a
--provenance opt-in).
- Normalize the build so the hash is machine-independent (
--remap-path-prefix et al.) — likely fragile across toolchains.
Repo-side normalization downstream was considered and rejected: it would re-implement lockfile parsing in a justfile.
Downstream evidence: polymorph-components/polymorph-webcrypto#312 (item 3), which this issue extracts so it can be tracked where the fix lives.
#44 ruled that
artifact_sha256is provenance, not identity:lock --checkignores it. Butlock-updatestill rewrites the field with a machine-dependent value — rustc embeds absolute paths, so a guest built from a git/registry dependency (or any out-of-workspace path) hashes differently per machine — and every lock regeneration on any machine therefore carries a meaningless hash-line diff, even when the case inventory is unchanged.Observed repeatedly downstream, where "the diff is the review surface" is the lockfile's whole point:
lock-updatechurnedartifact_sha256again, unrelated to the change under review.Options, in rough preference order from the downstream perspective:
lock-updateto preserve the committedartifact_sha256when the case inventory is unchanged (diff appears only when something identity-relevant moved).--provenanceopt-in).--remap-path-prefixet al.) — likely fragile across toolchains.Repo-side normalization downstream was considered and rejected: it would re-implement lockfile parsing in a justfile.