[tahoe-dev] Tahoe-LAFS is widely misunderstood

[Chris Palmer]

Greg Troxel writes:

> > * For clients and servers that trust each other and want to be tightly
> >   integrated, the server could know the directory descriptors and thus could
> >   compute what segments are no longer used
> 
> That breaks the primary security property.

Right, which is why it is only for clients and servers that trust each other
and want to be tightly integrated. For example, it might be very useful for
web servers (Octavia clients) to read in parallel from back-end Octavia
servers in the same server rack, instead of having everyone pound an NFS
server. In the beginning I had toyed with an alternative cipher suite,
(NULL,HMAC-SHA-512), to optimize for this deployment scenario. (NULL instead of
AES-256-CBC.)

> Those are all fair points.  But, you're describing an architecture within
> which one can make implementation choices and implementations, and it's
> somewhat awkward to make simplicitly comparisons between an architecture
> and running code.

Admittedly.

>   Be able to use FUSE to mount tahoe, and have that interface be
>   sufficiently rich and usable that most people almost never want to use
>   the CLI, and *never* want to use the WUI.
> 
>   I wouldn't mind a cron job to run "tahoe deep-check --repair --add-lease"
>   every few days via the CLI, or using the CLI for making new roots to
>   mount.

I would go further: The WUI is a security vulnerability.


-- 
http://noncombatant.org/