[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
 Keywords:                 |  Launchpad Bug:
---------------------------+-------------------------
 IRC user "joepie91" noticed that changing a filecap like:

 {{{URI:CHK:wfnqcotc4ceokosmfobofjzoya:qcof5dae7usfth4zvti7fmievpsofu25lgcmdq7q2cnebg3txyfq:3:10:29680}}}

 to

 {{{URI:CHK:wfnqcotc4ceokosmfobofjzoya:qcof5dae7usfth4zvti7fmievpsofu25lgcmdq7q2cnebg3txyfq:3:10:29681}}}

 (by changing the last character, raising the filesize by one) causes the
 following exception to be raised:

 {{{
 2011-09-06 21:24:27-0700 [-] Unhandled Error
  Traceback (most recent call last):
   File "/Users/warner2/stuff/tahoe/tahoe-git-
 hanford/src/allmydata/immutable/downloader/node.py", line 492, in
 _check_ciphertext_hash
    raise BadCiphertextHashError(msg)
  allmydata.immutable.downloader.common.BadCiphertextHashError: hash
 failure in ciphertext_hash_tree: segnum=0, SI=lfkjg4jkgzee
 }}}

 I was able to duplicate it locally against current trunk.

 It looks like 1: we're relying upon something in the filecap that should
 merely be a hint, and 2: we're throwing a particularly weird error
 message. A hash mismatch in the {{{ciphertext_hash_tree}}} either
 indicates a failure in zfec decoding, or a deliberately malformed file
 (in which the original {{{ciphertext_hash_tree}}} was computed over the
 wrong data, then included in the UEB). So my guess is that we're
 computing the predicted segment size from the filecap hint, but then not
 updating it when the shares' UEBs tell us that the hint was wrong, and
 trying to decode with the wrong data.

 The test case for this should be pretty straightforward: upload a file
 with a couple of segments, produce a mangled filecap, attempt a
 download. The download ought to succeed. If we want to be picky about
 the filecap being the source of truth, then we're allowed to fail, but
 we need a better error message than {{{BadHashError}}} (maybe something
 about "corrupt filecap" or "file size mismatch"). But I think success is
 arguably more correct. (note: the same argument may apply to mismatches
 in k and N).

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