[tahoe-dev] backup, revision control

[David-Sarah Hopwood]

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
> system.

In practice it's pretty much infeasible to protect against compromise of
a live system written in any language, at least with current operating
systems.

> [...] 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
    interoperable version).

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110118/a80a52ef/attachment-0001.pgp>