[tahoe-dev] [tahoe-lafs] #833: reject mutable children when *reading* an immutable dirnode

[tahoe-lafs]

#833: reject mutable children when *reading* an immutable dirnode
---------------------------------------------+------------------------------
 Reporter:  warner                           |           Owner:  warner  
     Type:  defect                           |          Status:  assigned
 Priority:  critical                         |       Milestone:  1.6.0   
Component:  code-dirnodes                    |         Version:  1.5.0   
 Keywords:  integrity forward-compatibility  |   Launchpad_bug:          
---------------------------------------------+------------------------------

Comment(by warner):

 hm. I guess immutability is a property of the object, while
 readability/writeability is a property of the cap (think of the cap as a
 facet here). There's no such thing as an "immutable cap" to a mutable
 object.

 So maybe instead of "imm_uri" we should put another property on the JSON
 stuff we return, an "immutable" boolean.

 Of course, for caps-from-the-future, we'd leave this empty, because we
 don't know. Then we'd need to decide whether the webapi promises
 {{{all([x.immutable for x in immdir.list()]) == True}}} (in which case it
 would be obligated to strip out everything except known-immutable
 children), or whether it promises something smaller.

 WRT to anticipated future caps, I can currently imagine append-only caps,
 write-with-storage-authority caps, verify/repair caps, destroy caps,
 revocation caps, and others. Very few of these cleanly break down into
 mutable/immutable, or read/write. So I don't see an overwhelming amount of
 value to trying to anticipate them too much, and therefore having current
 code attempt to deduce much of anything about caps-from-the-future.

 So yes, I believe that 1.6 should treat all unrecognized caps as unknown,
 and any operation that promises to only return caps that are known to have
 some particular property should be obligated to either filter out
 unrecognized caps or mark them in some way such that clients can easily
 tell which are which.

 I'm still undecided as to whether marking nodetype=={{{unknown}}} or
 removing them entirely is better.

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