id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
1529	"corrupted filesize in CHK filecap causes unexpected ""bad hash error"""	warner		"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).
"	defect	new	major	soon	code-encoding	1.9.0a1		error download immutable