[tahoe-lafs-trac-stream] [tahoe-lafs] #1529: corrupted filesize in CHK filecap causes unexpected "bad hash error"

[tahoe-lafs]

#1529: corrupted filesize in CHK filecap causes unexpected "bad hash error"
-------------------------------+---------------------
     Reporter:  warner         |      Owner:
         Type:  defect         |     Status:  new
     Priority:  major          |  Milestone:  soon
    Component:  code-encoding  |    Version:  1.9.0a1
   Resolution:                 |   Keywords:
Launchpad Bug:                 |
-------------------------------+---------------------

Comment (by warner):

 After discussing it with Zooko, I agree with his description: the filecap
 is authoritative/canonical. If we fetch a share that contains a UEB with a
 filesize that disagrees with the filecap, we should treat that share as
 invalid, and throw a useful error ({{{FilecapFilesizeMismatchError}}}?,
 although {{{BadURIExtension}}} is even better). The filecap's filesize is
 not just a hint.

 The "new" immutable downloader currently ignores all the share fields it
 doesn't need, including the UEB's filesize field. In this case, I think
 it's better that the downloader explicitly (one might say gratuitously)
 compares the UEB's filesize against the filecap's filesize and throw
 {{{FilecapFilesizeMismatchError}}}, rather than pretending that the UEB's
 filesize is a mistake and attempting to decode the file with the filecap's
 filesize (which will result in the unhelpful ciphertext_hash_tree error in
 this ticket). Think of it as bringing the error forward to a better place.

 Note that the root issue here is that the filesize is redundant: the file
 can be completely specified by just the readkey and the UEB hash. But it's
 awfully handy to include the filesize, k, and N in there, both to speed up
 downloads (parallelizing an appropriate number of DYHB queries) and to let
 deep-size run without actually fetching file data. Ideally, filecaps would
 only contain the minimal set of data necessary to retrieve the file.
 Having extra data there means we have to specify what happens when the
 extra data in the filecap disagrees with the data in a validated share,
 which means doing more work during download that can only possibly cause a
 failure.

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