Opened at 2009-11-30T23:48:48Z
Last modified at 2017-03-07T18:38:09Z
#847 new task
create internal VerifierNode/RepairerNode classes
Reported by: | warner | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | soon |
Component: | code | Version: | 1.5.0 |
Keywords: | confidentiality integrity verify repair | Cc: | |
Launchpad Bug: |
Description (last modified by daira)
I'd like to have a set of VerifierNode and/or RepairerNode classes, created by the nodemaker, which implement IVerifiable and IRepairable (but not IFilesystemNode). This would be the first step towards fixing #482, by giving us an object that represents what we can do with a given verifycap/repaircap.
I'm thinking that these objects might be created with or without the integrity information. If without, it would just wrap a storage-index. It'd be nice to be able to find out what the SI represents, determine its UEB value (by consensus, not by cryptographically-ensured integrity values), and then verify/repair the file on the assumption that those shares were correct.
Change History (5)
comment:1 in reply to: ↑ description Changed at 2009-12-06T00:15:43Z by davidsarah
- Keywords integrity repair added
comment:2 Changed at 2009-12-20T15:43:50Z by davidsarah
- Keywords verify added
comment:3 Changed at 2010-02-11T01:25:25Z by davidsarah
- Keywords confidentiality added
- Milestone changed from eventually to 1.7.0
- Priority changed from minor to major
comment:4 Changed at 2010-05-30T21:30:41Z by zooko
- Milestone changed from 1.7.0 to soon
comment:5 Changed at 2017-03-07T18:37:12Z by daira
- Description modified (diff)
See https://github.com/tahoe-lafs/tahoe-lafs/pull/408 , which adds IVerifyNode.
Replying to warner:
When would you have a storage index but not a verify cap? If we had traversal/deep-verify caps, would that obviate the need for this feature? It seems risky to be encouraging attempts to repair a file without having sufficient information to be sure that the repair is correct.