durability: document the relayed-evidence trust boundary + defence-in-depth guards#128
Merged
Merged
Conversation
…loods Two cheap defence-in-depth guards on the peer durability pull. Neither is a trust control — the peer is trusted to assert its own durability — they turn a peer bug or version skew into a loud refusal instead of a silent local effect. - Add store.KnownVerifyMethod and refuse a non-empty verify_method the build does not recognise in validateComponent. Previously an unknown method was stored and then silently treated as unverified by the offload gate; now it is rejected at receipt. Empty (legitimately "unverified") still passes. - Cap distinct origins one pull will resolve (maxOriginNodesPerPull) so a runaway peer cannot grow the local nodes table without bound via GetOrCreateOriginNode. A real volume references a handful of origins. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KE9A1VTdw7k1GQq87fQyfx
Add an offload-v1 section to SAFETY-AUDIT.md framed for the single-operator deployment (laptop + NAS, all owned, adversary is entropy not a hostile peer): - D1 documents the relayed-evidence trust boundary in the durability pull (direct self-verified vs peer-asserted components), states the accepted decision to trust an in-domain NAS, and records the two defence-in-depth guards added alongside. - D2 documents that the content-addressed offsite push proves presence+size and decrypt-input correctness but not decrypt-output correctness, and sketches an opt-in, NAS-local read-back-decrypt-rehash verification as the proportionate close. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KE9A1VTdw7k1GQq87fQyfx
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
2 participants
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.
Targets
offload-v1(notmain). Follow-up to the review of #126.The review of #126 flagged the peer durability pull as the place where, in the worst case, a peer's assertion could drive a premature local
offload. Working it through for the intended deployment — a single operator whose laptop and NAS are both machines they own and hold the only credentials to — the conclusion is that the relayed-evidence trust is an accepted boundary (an in-domain NAS that lies about durability is already a compromised archive), not a vulnerability to engineer away. This PR writes that decision down and adds two cheap guards that turn bugs into loud failures.Code — defence-in-depth (not trust controls)
store.KnownVerifyMethod;validateComponentnow refuses a non-emptyverify_methodthis build doesn't recognise. Previously an unknown method was stored and then silently treated as unverified by the offload gate — now a peer bug or version-skew string is rejected at receipt. Empty (legitimately "unverified") still passes.pullDurabilityrefuses a pull naming more thanmaxOriginNodesPerPull(256) distinct origins, so a runaway/buggy peer can't grow the localnodestable without bound viaGetOrCreateOriginNode. A real volume references a handful of origins; the cap only converts a flood into an observable refusal.TestValidateComponentVerifyMethod(allow-list) andTestPullDurabilityCapsOriginNodeCreation(cap).Docs —
SAFETY-AUDIT.md(offload-v1 section)Validation
go vet ./...,go build ./...,go test ./sync ./storeall green;gofmtclean. (golangci-lintcouldn't run in my environment due to a Go version skew — please let CI run it.)No schema change (adds a function and a doc section only).
🤖 Generated with Claude Code
https://claude.ai/code/session_01KE9A1VTdw7k1GQq87fQyfx
Generated by Claude Code