tahoe-lafs/trac-2024-07-25

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

New issue

Open

opened 2008-07-01 23:41:08 +00:00 by warner · 2 comments

warner commented

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

Owner

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.

tahoe-lafs added the

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

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

tahoe-lafs added

and removed

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

davidsarah commented

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

Author

Owner

See also #847.

See also #847.

davidsarah commented

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

Author

Owner

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?

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.

No labels

LeastAuthority.com automation

cannot reproduce

code-frontend-cli

code-frontend-ftp-sftp

code-frontend-magic-folder

code-frontend-web

code-peerselection

dev-infrastructure

somebody else's problem

was already fixed

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#482

No description provided.