build a checker/verifier that can work from just SI #482

New Issue

warner · 2008-07-01T23:41:08Z

warner commented

2008-07-01 23:41:08 +00:00

The current checker code requires a read-cap, or at least a verifier cap. We should have a checker/verifier that can work from just the storage index. It should read all shares and verify all hashes against the UEB. It should compare the UEB from each share against each other and reject the minority versions. If a verifier cap is available, it should compare the UEB from the shares against the UEB hash from the verifier cap.

Files which fail the check (fewer shares than expected) should be reported. Shares which fail their hash checks (or disagree with the majority, or with the verifier cap) should be reported.

The current checker code requires a read-cap, or at least a verifier cap. We should have a checker/verifier that can work from just the storage index. It should read all shares and verify all hashes against the UEB. It should compare the UEB from each share against each other and reject the minority versions. If a verifier cap is available, it should compare the UEB from the shares against the UEB hash from the verifier cap. Files which fail the check (fewer shares than expected) should be reported. Shares which fail their hash checks (or disagree with the majority, or with the verifier cap) should be reported.

warner added the

labels 2008-07-01 23:41:08 +00:00

warner added this to the undecided milestone 2008-07-01 23:41:08 +00:00

tahoe-lafs added

enhancement

and removed

task

labels 2009-12-06 00:06:31 +00:00

davidsarah commented

2009-12-06 00:18:57 +00:00

See also #847.

davidsarah commented

2010-02-11 01:14:05 +00:00

Would we really need this if we had fixes for #568 and #625? Verification just from the SI would not be able to detect malicious corruption -- only some cases of accidental corruption. Under what circumstances would we have the SI and not the verify cap?

Sign in to join this conversation.