[tahoe-dev] backup, revision control
david-sarah at jacaranda.org
Tue Jan 18 02:25:27 UTC 2011
On 2011-01-17 21:35, Brian Warner wrote:
> On 1/16/11 4:53 AM, Greg Troxel wrote:
>> Command line tools for tahoe are less functional than WUI, so it's
>> too tempting to use the WUI, which means firefox/etc. handles caps,
>> which is obviously unsafe. Getting to the point where I don't want
>> to use the WUI beyond seeing server status is one of my gating
>> conditions before real use.
> Yeah, we may need some tahoe-specific GUI (which speaks HTTP to
> localhost behind the scenes), to keep the caps away from
> traditionally-leaky browsers, but still make things easier than a CLI.
Note that you can already use file browsers that speak SFTP. In that
case, the file browser does not get any caps. The root directory cap is
configured in the gateway.
What this doesn't give you is the ability to obtain the cap URI for a
given object (file or directory) via the file browser interface, and
share it with someone else. It does allow you to access a cap that
you've received that way, via the uri/ directory.
You could use an SFTP browser for most operations, and the tahoe CLI
to print out the cap of any object you want to share.
(That's inconvenient at the moment, but
<http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1299> would make it easier.)
Alternatively, a plugin for the file browser could be written to display
the caps for a selected object; this is considerably easier than writing
a browser GUI from scratch.
The SFTP protocol has some limitations as a filesystem access protocol,
though, because it doesn't support remote-to-remote file copies or
moves without dragging bytes across the wire, and there is no support
for recursive operations without doing the directory traversals on
the client (unlike other candidate filesystem access protocols such as WebDAV)
>> With gpg, one uses the agent which holds the private key, and goes to
>> great lengths to wipe memory, avoid swapping, etc. I have no reason
>> to believe that the python code in tahoe client/server does this, but
>> maybe I'm totally confused on this point.
> You're right, the tahoe code makes no attempt to protect secrets in RAM.
> In addition to being really difficult in general, a language like python
> probably makes it impossible.. when I was looking into implementing the
> Pynchon Gate in python, I concluded that you'd want to have encrypted
> swap, use a separate process for long-term keys to achieve some level of
> forward-security, and give up on protecting against compromise of a live
In practice it's pretty much infeasible to protect against compromise of
a live system written in any language, at least with current operating
> [...] Git gets its speed (specifically its super-efficient network transport,
> moving as little data as possible in one or two roundtrips) because both
> sides of the wire get to know about the object graph. To make Tahoe work
> this fast, we'd have to reveal the directory structure (or something
> similar) to the storage servers. We'd also probably need to combine
> small files together into single bundles to make things more efficient,
> which would complicate the find-grained sharing thing.
The latter is <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/204>.
[*] SFTP would have been an excellent basis for a complete filesystem
access protocol -- and still would be. Unfortunately, standards
politics got in the way: the IETF working group that was standardizing
it hadn't been chartered to develop such a protocol, and so for
no reason that makes any technical sense, they disbanded without
producing an RFC (leaving considerable confusion about which version
should be used, although Tahoe's SFTP server uses the most
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 292 bytes
Desc: OpenPGP digital signature
More information about the tahoe-dev