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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
