URIs do not refer to unique files in Allmydata Tahoe

[zooko]

As Christian Grothoff observed, it is possible for an uploader to make some shares produce one file, and other shares produce another file. The integrity check that is currently required -- the Merkle Tree over the shares -- ensures that only one set of shares can be used for a given read-cap or verify-cap, but it doesn't ensure that only one file can be produced.

The intended semantics of Tahoe immutable files are that there is only one file that can be denoted by a given read-cap or write-cap, so this is a bug. It isn't a major security issue for the typical current use case, since only the original uploader can construct a file to have this ambiguity -- this cannot be used to attack the integrity of a file if you are not the original uploader of that file. However, it isn't the property that we want and it could be used for mischief, so we're going to fix it.

Christian's advisory:

​http://crisp.cs.du.edu/?q=node/88

His post to tahoe-dev:

​http://allmydata.org/pipermail/tahoe-dev/2008-July/000689.html

[zooko]

I updated docs/known_issues.txt to describe this issue.

[zooko]

This was fixed by 9461887e0a98274e and released in Tahoe 1.2.0. The known_issues.txt describes it, r2788, line 37 ("issue 9"):

​http://allmydata.org/trac/tahoe/browser/docs/known_issues.txt?rev=5b84721c7ec215e8#L37

[zooko]

Christian Grothoff won a place on the I Hacked Tahoe! Hall of Fame for this:

​http://hacktahoe.org

[davidsarah]

For historical reference, the URL of Christian's original advisory should have been ​http://crisp.cs.du.edu/?q=node/90