[tahoe-lafs-trac-stream] [tahoe-lafs] #1526: make sure the new MDMF extension field is forward-compatible and safe

[tahoe-lafs]

#1526: make sure the new MDMF extension field is forward-compatible and safe
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:
         Type:  defect   |     Status:  new
     Priority:           |  Milestone:  1.9.0
  critical               |    Version:  1.9.0a1
    Component:  code-    |   Keywords:  forward-compatibility mdmf design-
  mutable                |  review-needed
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 After talking with zooko on IRC, I'm in favor of making 1.9 tolerate and
 ignore everything past the fingerprint. That puts no constraints on the
 extension fields (although 1.10 or some later version might impose some,
 and including "k" will be the first extension I'd recommend).

 If we're really not using those hints at all right now, then the code
 changes to support this should be pretty simple. I think we may be parsing
 'k' and 'segsize' and populating the Filenode with them, in which case
 it's possible for behavior to be affected, and we should change it to not
 pre-populate those values.

 I'll figure out how to implement this: I think it means a test that the
 URI parser accepts (and equates) filecaps with extra stuff after the
 fingerprint (so {{{URI:MDMF:$writekey:$fingerprint:blahblah}}}), changes
 to the URI parser's regexp, and changes to the Filenode constructor (to
 not extract+populate the extension fields). It might also involve changes
 to the URI constructor, to not provide those fields either.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1526#comment:7>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage