Repository navigation
BinaryCacheStore: verify NarHash/NarSize before writing a narinfo - #766
Open
czawistowski-nvidia wants to merge 1 commit into
Open
czawistowski-nvidia wants to merge 1 commit into
czawistowski-nvidia wants to merge 1 commit into
Conversation
BinaryCacheStore::uploadData() computes the hash and size of the NAR it receives, but never compared them with the ValidPathInfo it publishes: the check in addToStore() has been commented out since 2020 (9fbc31a, "Get rid of Hash::dummy from BinaryCacheStore"), and addMultipleToStore() never had one. So a source path that changed after registration, or a nario or daemon client with wrong path info, produced a .narinfo that every client then rejects with "hash mismatch importing path". Check both in uploadData(), before anything is written to the cache, so the upload fails instead. This covers addToStore(), addMultipleToStore() (nix copy --to) and addToStoreFromDump(), whose info is computed from the same hash and so always matches. LocalStore::addToStore() already performs the same check unconditionally, regardless of repair and checkSigs.
|
Warning Review limit reached
This review includes 4 billable files and costs up to $1.00. Or wait 59 minutes for your next included review. View limit details
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
BinaryCacheStore::uploadData()hashes every NAR it uploads, but never compares the result with theValidPathInfoit publishes:addToStore()the check has been commented out since Get rid of Hash::dummy from BinaryCacheStore NixOS/nix#3935 (2020), withFIXME reinstate these, once we can correctly do hash modulo sink as needed. We need to throw here in case we uploaded a corrupted store path.addMultipleToStore(), whichnix copy --touses, never had a check.So
nix copy --to <cache>of a store path whose contents changed after registration, ornix nario import --store <cache>of a nario with wrong path info, succeeds and publishes a.narinfothat doesn't match its NAR. Every client then fails to substitute that path withhash mismatch importing path, later and on another machine, instead of the upload failing.Change
uploadData()now throwshash mismatch uploading path '…' to '…'orsize mismatch uploading path '…' to '…'when the NAR hash or size it computed differs from theValidPathInfothatmkInforeturns. It throws before writing the NAR, the listing, the debuginfo links or the.narinfo. The hash and size were already being computed, so the check costs nothing.The check is unconditional, because no legitimate caller passes info that doesn't match its NAR:
Hash::dummycallers that motivated the FIXME were moved toaddToStoreFromDump()in the same PR, which builds its info from the computed hash.copyPaths()/copyStorePath()streamnarFromPath()unchanged;makeContentAddressed()computesnarHash/narSizefrom the rewritten NAR.LocalStore::addToStore()already rejects mismatches regardless ofrepairandcheckSigs, so a mismatched.narinfowas never usable by any client.Testing
New functional test
binary-cache-upload-verify.sh:nix copy --to file://must fail for both;nix nario import --store file://must fail;.narinfomay be written, and good paths must still upload.Without the
libstorechange the test fails (nix copysucceeds). With it, on this branch:binary-cache-upload-verify,binary-cache,binary-cache-compression,nix-copy-ssh,nix-copy-ssh-ng,export,repair,fetchClosure,make-content-addressed,signingandnix-store-testspass.