tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

add desideratum: Don't provide an affordance for diminishing caps by editing them, or else make sure that the actual effect of doing so is the same as the intended effect. 

[Imported from Trac: page NewCapDesign, version 26]
zooko 2011-11-22 19:02:30 +00:00
parent 152074e891
commit 5683e8b6c1
1 changed files with 2 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
NewCapDesign.md

@ -221,6 +221,7 @@ several lower bounds on the length:
`tahoe cp tahoe://CAP local/foo.txt` copies from a specific URI, `tahoe cp tahoe://CAP local/foo.txt` copies from a specific URI,
while `tahoe cp tahoe:blah local/foo.txt` copies from a child of while `tahoe cp tahoe:blah local/foo.txt` copies from a child of
the "tahoe:" alias). the "tahoe:" alias).
**Note that double-slash means "there is a naming authority" (see RFC 3986). I think most people's understanding of caps is that there is no naming authority (i.e. a remote server which you completely rely on to decide what value a name within its domain should denote). I suppose we might fit the semantics of RFC 3986 if we claim that the thing we have there (which will probably be a crypto value derived in complex ways from the plaintext of the file and/or a public key) *is* a naming authority.**
* I'd like to make it easy to layer uses on top of one another: since * I'd like to make it easy to layer uses on top of one another: since
directories are just a specific way of interpreting the contents of a directories are just a specific way of interpreting the contents of a
(mutable) file, let's make the directory cap be closely related to the (mutable) file, let's make the directory cap be closely related to the
@ -234,6 +235,7 @@ several lower bounds on the length:
trivial. Another way to think about this is that if our filecaps were trivial. Another way to think about this is that if our filecaps were
verbose s-expressions, these caps could be expressed as "(readonly verbose s-expressions, these caps could be expressed as "(readonly
(mutable cryptobits))" and "(directory (readonly (mutable cryptobits)))". (mutable cryptobits))" and "(directory (readonly (mutable cryptobits)))".
* Don't provide an affordance for diminishing caps by editing them, or else make sure that the actual effect of doing so is the same as the intended effect. This actually happened to an LAE customer: they sent us a transcript of their shell session which had their write cap init, and they truncated off the right-hand side of the cap, intending to thus preserve confidentiality of their data. Unfortunately for them, the right-hand side of the (current) write cap format is the integrity-checking bits, not the write-authority bits! The remaining left-hand-side of the cap that they sent was enough to let us (or anyone else who saw their mail) read and overwrite all of their files. This wouldn't have happened if the cap had been a compact thing with no visible separations, like "tahoe:WD1WDDy975ZJkrU7XZTxAB39kmnfxYk3zDb", or if it had been ordered so that the most powerful bits were left-most.
* provide for verifycaps, repaircaps, and traversalcaps (#308, #217). * provide for verifycaps, repaircaps, and traversalcaps (#308, #217).
Repaircaps in particular may require a grant of storage authority, which Repaircaps in particular may require a grant of storage authority, which
might entail a cap format that can accept arbitrary extra non-hierarchical might entail a cap format that can accept arbitrary extra non-hierarchical