[tahoe-dev] [tahoe-lafs] #625: Can't repair read-only dirnodes/mutable-files (was: Deep-check chokes on readonly dirnodes that need repair)

[tahoe-lafs]

#625: Can't repair read-only dirnodes/mutable-files
---------------------------+------------------------------------------------
 Reporter:  francois       |           Owner:  warner  
     Type:  defect         |          Status:  assigned
 Priority:  minor          |       Milestone:  1.5.0   
Component:  code-dirnodes  |         Version:  1.3.0   
 Keywords:                 |   Launchpad_bug:          
---------------------------+------------------------------------------------
Changes (by warner):

  * milestone:  1.4.0 => 1.5.0


Comment:

 Nope, this is getting bumped again.. we haven't made enough progress on
 it. The new test harness is in place ({{{NoNetworkTestGrid}}}), but I'm
 still not sure how we should handle it. The root issue is that readonly
 dirnode don't give us enough information to compute the Write Enabler (by
 design), and when repair needs to create new shares, it must give those
 shares a Write Enabler so that later writers can modify those shares.

 We've considered changing the storage-server protocol to have the server
 validate shares (by checking their signatures): this would remove the need
 for Write Enablers, but would also obligate servers to know more about the
 client's data format (causing version dependencies between clients and
 servers) and increasing the workload of the servers. Despite these
 tradeoffs, I think we're likely to move in this direction when we
 implement Accounting, since Write Enablers are a nuisance (and require an
 encrypted transport layer, which it would be nice to avoid).

 But until then, we may have to decide between being able to repair read-
 only mutable files, and being able to modify those shares later. One
 possible change (that wouldn't involve modifying any protocols) would be
 to have the repairer provide an all-zeros Write Enabler, and then if
 anyone tries to modify the share again later, have the server validate the
 signatures and replace the WE if they check out. This would have some
 security implications, in particular making it possible to cause rollbacks
 in certain situations.

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