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

tahoe-lafs trac at allmydata.org
Sat Jan 16 17:28:10 UTC 2010

#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 davidsarah):

 Overnight I thought of the following additional option, which has similar
 forward-compatibility advantages to FORWARD_COMPAT_METADATA but has fewer
 constraints on the  future URL design:

  * PREFIXED_RO_URI: include a directory entry for an unknown child link of
 an immutable directory, but prefix {{{ro_uri}}} with "{{{imm.}}}" (and
 omit {{{rw_uri}}}).

 Note that this doesn't imply that the new format would have to use
 "{{{imm.}}}" -- that prefix would ''only'' occur on URLs from the past.
 When we add support for the new format, the future client would see the
 "{{{imm.}}}" prefix and check that the cap is immutable; if it is then it
 would work correctly.

 (We might end up registering both "{{{lafs:}}}" and "{{{imm.lafs:}}}" in
 order to make this work in more cases, but I don't think that's a problem,
 and it's not strictly necessary. Anyway, there are already
 [http://www.iana.org/assignments/uri-schemes.html URI schemes] containing

 In retrospect this is similar to something Zooko suggested on IRC ('mangle
 the cap by prepending "I'M NOT REALLY A CAP"'), except that "{{{imm.}}}"
 just means that the future client must check that it is an immutable cap.

 The effect of prepending "{{{imm.}}}" with the current webapi is to
 display {{{"GET unknown: can only do t=info, not t="}}}, which is safe but
 ugly. We should fix that (it's ticket #884).

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

More information about the tahoe-dev mailing list