[tahoe-dev] IRC isn't a reliable way to learn about Tahoe-LAFS

[Brian Warner]

On 7/26/10 12:32 PM, Zooko O'Whielacronx wrote:

> Anyway, <so> was wrong that repair works on immutable files and
> directories given a verify cap to the thing—instead you require a
> read-cap to the thing. Repair also works on mutable files and
> directories given a write-cap to the thing (which means you can't let
> someone repair a mutable thing while withholding from them the ability
> to read it and even to change it).

An update on this:

 in v1.7.1:
  mutable files require a writecap to repair
  immutable files require a readcap to repair

 in the upcoming v1.8.0:
  mutable files will still require a writecap to repair
  immutable files will require a verifycap to repair

The problem with mutable files is the shared "write-enabler" secret. If
you were to repair a mutable file using only a readcap or verifycap, you
wouldn't be able to tell new servers what write-enabler they ought to
accept for future updates. So you could improve the health of the
current version of the file, but the real writecap holder would not be
able to replace those new shares with later versions, meaning the file
would slowly become sort of read-only. We will need to move to DSA
keypairs (instead of shared secrets) to fix this.

The issue with immutable files in 1.7.1 is more of a missing API than a
fundamental protocol limitation. When Zooko wrote the immutable repairer
(about two years ago), he wisely based it on using a verifycap instead
of a readcap, so most of the support is in place already. My upcoming
#798 new-downloader code (getting ready to land soon) adds support for
downloading ciphertext from a verifycap, and I'm hopeful that we can add
the remaining pieces (webapi code to expose the new VerifyNode instances
and their .read()/.repair() methods) by the time we release 1.8.0.

cheers,
 -Brian