[tahoe-dev] [tahoe-lafs] #654: make the storage index be the verifier cap

[tahoe-lafs]

#654: make the storage index be the verifier cap
---------------------------+------------------------------------------------
 Reporter:  zooko          |           Owner:           
     Type:  enhancement    |          Status:  new      
 Priority:  major          |       Milestone:  undecided
Component:  code-encoding  |         Version:  1.3.0    
 Keywords:                 |   Launchpad_bug:           
---------------------------+------------------------------------------------
 As I discuss in [http://allmydata.org/pipermail/tahoe-
 dev/2009-March/001388.html this mailing list post], we could use the
 verifycap for the purpose of a storage index.

 The big advantage of this to me is ''reducing the number of concepts by
 one''.  This would prevent, for example, misunderstandings such as Shawn
 Willden's misapprehension about overwriting shares (to which my letter is
 a response).

 Another advantage would be that the storage server (as well as anyone
 else) could verify that the share is a fitting share for that storage
 index.  This would neatly solve all questions about the correctness of
 storage indices, such as:
  * race conditions on upload (such as what if one storage server sees that
 you are beginning to upload a file with storage index X, and then turns
 around and starts uploading a different file with storage index X on all
 the other storage servers before you get to them),
  * life cycle of the share ; now that we're introducing share death in a
 future release of tahoe, we have to revisit our earlier assumptions about
 "once there always there" within a given storage server

 This might also allow greater similarity between the immutable and mutable
 share storage protocols, if both of them used the verify cap as the
 storage index.  The mutable case has much worse issues about security and
 consistency, of course, and my current assumption is that it, too, could
 be strengthened and simplified by requiring the storage server to verify
 the correctness of each share.  (Although simpler from some perspectives,
 this would actually be more complicated for the storage servers because
 they would have to understand enough about the share layout to verify the
 correctness.  Also it would cost quite a bit of CPU to perform the digital
 signature checks on the mutable shares.)

 I vaguely recall that Brian pointed out some significant added problems or
 issues with this approach, so hopefully he'll follow up on the list or
 this ticket and remind me what they were.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/654>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid