Today mops install re-hashes every file in .mops/ against mops.lock on every successful run, but does not verify file integrity at download time (installMopsDep writes bytes from the storage canister straight into the global cache). This is backwards from npm and cargo, which verify at the trust boundary (network → disk) and then trust the local cache.
Net effect: mops pays O(N) hashing on every install for a security guarantee it doesn't actually deliver end-to-end (a registry returning bad bytes is recorded into the lock as "correct" on first install).
Proposed direction, for the next major:
- Verify on download. In
installMopsDep, hash each downloaded file and compare against the registry-published hash before writing to the global cache. Fail loudly on mismatch.
- Stop re-hashing
.mops/ on every install. Drop checkLockFile's on-disk walk from the install hot path. Optionally retain it behind an explicit mops verify command for paranoid users / CI.
mops.lock becomes a record, not a recurring check. It pins the hashes seen at first install. Future downloads against a registry returning different bytes are caught at download time against the lock value.
Goal: match the npm ci / cargo build --locked trust model — verify once at the boundary, then trust the cache.
Knock-on: shrinks the corrupt-lock failure surface (#514) to lock-internal corruption only, which a self-checksum on the lock body handles cleanly. Eliminates the "install is unexpectedly slow because it re-hashes everything" footgun.
Related: #514, #515, #516.
Today
mops installre-hashes every file in.mops/againstmops.lockon every successful run, but does not verify file integrity at download time (installMopsDepwrites bytes from the storage canister straight into the global cache). This is backwards from npm and cargo, which verify at the trust boundary (network → disk) and then trust the local cache.Net effect: mops pays O(N) hashing on every install for a security guarantee it doesn't actually deliver end-to-end (a registry returning bad bytes is recorded into the lock as "correct" on first install).
Proposed direction, for the next major:
installMopsDep, hash each downloaded file and compare against the registry-published hash before writing to the global cache. Fail loudly on mismatch..mops/on every install. DropcheckLockFile's on-disk walk from the install hot path. Optionally retain it behind an explicitmops verifycommand for paranoid users / CI.mops.lockbecomes a record, not a recurring check. It pins the hashes seen at first install. Future downloads against a registry returning different bytes are caught at download time against the lock value.Goal: match the
npm ci/cargo build --lockedtrust model — verify once at the boundary, then trust the cache.Knock-on: shrinks the corrupt-lock failure surface (#514) to lock-internal corruption only, which a self-checksum on the lock body handles cleanly. Eliminates the "install is unexpectedly slow because it re-hashes everything" footgun.
Related: #514, #515, #516.