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

tahoe-lafs trac at allmydata.org
Mon Jan 18 20:04:25 UTC 2010

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

Comment(by davidsarah):

 Replying to [comment:32 davidsarah]:
 > Replying to [comment:30 zooko]:
 > > Replying to [comment:28 davidsarah]:
 > > > If unknown caps (i.e. unknown to the webapi server) are allowed to
 be returned in directory reads, then the webapi can't ensure this property
 for such caps. I'm leaning toward just documenting that.
 > >
 > > Should the webapi server tag such caps with something like {{{unk.}}}
 so that the fact that they came from a context where this property
 couldn't be verified is not lost?
 > What would the webapi client do with that fact? {{{imm.}}} and {{{ro.}}}
 are associated with specific conformance requirements, but {{{unk.}}}
 wouldn't be -- it would just be a hint that the webapi client shouldn't
 assume something. It is easier to document that it shouldn't ever make
 that assumption. (Note that a webapi client could always decode the caps
 and check that they are consistent.)

 ... although it should probably avoid decoding caps since that is the
 webapi server's responsibility. Which reminds me: we don't seem to have
 either a webapi operation or a CLI command to diminish a cap.

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

More information about the tahoe-dev mailing list