[tahoe-dev] [tahoe-lafs] #957: embed security metadata in URL
tahoe-lafs
trac at allmydata.org
Tue Feb 16 12:21:34 PST 2010
#957: embed security metadata in URL
------------------------------------------------+---------------------------
Reporter: zooko | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: undecided
Component: code | Version: 1.6.0
Keywords: newcaps newurls integrity redirect | Launchpad_bug:
------------------------------------------------+---------------------------
Changes (by davidsarah):
* keywords: newcaps newurls integrity => newcaps newurls integrity
redirect
Comment:
In order for a petrified URL not to be subject to a rollback attack, it
would need to include a hash of the final contents (I was mistaken about
this in comment:2). The final version number is not sufficient, if the
write cap might have been compromised. Including a hash would make the URL
huge. (I/we had some ideas about how to obtain relatively short caps to a
specific version of a mutable object, but they're for the new cap
formats.)
We're starting to think that petrification should be implemented in terms
of permanent redirects ("moved permanently"). I.e. a petrified object is
just a mutable object that has been permanently redirected to an immutable
URI. To record that in a parent directory (#956), you would just update
the link in the parent to point to the new URI.
The advantage of this is that you can upload the final contents (either a
single file or a tree) as normal, check that they are correct, and only
then make the redirect. Also you can permanently redirect to a new mutable
object using the same mechanism, which is probably what you would want to
do if you've accidentally given away a write cap.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/957#comment:5>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list