id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
312	mutable file: survive encoding variations	warner	warner	"The current mutable.py has a nasty bug lurking: since the encoding parameters
(k and N) are not included in the URI, a copy is put in each share. The
Retrieve code latches on to the first version it sees, and ignores the values
from all subsequently-fetched shares. If (for whatever reason) some clients
have uploaded the file with different parameters (specifically different
values of k, say 3-of-10 vs 2-of-6), then we could wind up feeding 3-of-10
shares into a zfec decoder configured for 2-of-6, which would cause silent
data corruption.

The first fix for this is to reject shares that have encoding parameters that
differ from the values that we pulled from the first share, rejecting them
with a {{{CorruptShareError}}}. That will at least prevent the possible data
corruption.

The longer-term fix is to refactor Retrieve to treat k and N as part of the
'verinfo' index, along with seqnum and roothash and the salt. This
refactoring also calls for building up a table of available versions, and
then deciding which one (or ones) to decode on the basis of available shares
and highest seqnum. The new Retrieve class should be able to return multiple
versions, or indicate the presence of newer versions (that might not be
recoverable).
"	defect	closed	major	0.9.0 (Allmydata 3.0 final)	code-encoding	0.7.0	fixed	mutable