make immutable check/verify/repair and mutable check/verify work given only a verify cap

[zooko]

For immutable files, Check/Verify/Repair could do its work with only a verify cap, but currently the WAPI and the CLI seem to require a read cap. To fix this, relax the requirements of those front-ends so that they can make do with only a verify cap.

[warner]

I think that immutable check/verify/repair can work with only a verifycap, and that the internal classes (immutable.checker.Checker, immutable.repairer.Repairer) use verifycaps. The limitation is that the immutable FileNode class is the only way to get at the check() method, and it must be constructed with a readcap.

My thought is to create a new VerifierNode class, constructed with a verifycap. This class will provide the ICheckable interface, which is the one that contains the check() method.

The mutable checker/verifier should be able to work from a verifycap, so I'm thinking we can use the same technique (MutableVerifierNode.check). Mutable repair, however, requires a writecap, to generate the correct write-enabler on the new shares (so that writers can modify the new shares in the future). So MutableVerifierNode.check(repair=True) must be disallowed. One of the goals for DSA-based mutable files is to fix this limitation.

[zooko]

Let's release allmydata-tahoe-1.3.0 before fixing this ticket.

[warner]

Oh, also, if you do a GET on a verifycap, you could get the ciphertext. That would make VerifierNode instances provide ICheckable and IEncryptedReadable, but only real filenodes would also provide IPlaintextReadable/IReadable.

This would be most useful if it were possible to PUT ciphertext, moving the encrypted realm out beyond the tahoe node and into the HTTP client.

[davidsarah]

See also #625, which is about allowing mutable repair to work using a cap weaker than a write cap.

[davidsarah]

#578 was a duplicate.

[davidsarah]

I think we should try to fix this for 1.10. It's a clear instance of requiring excess authority. I'll have a look at what code changes are needed.

[warner]

FYI, nodemaker.py already knows how to create immutable verifier nodes, which have both check() and check_and_repair() methods.

My untested ​mutable-verifiernode branch adds mutable verifier nodes, with only check() (but not check_and_repair() due to #625).

So what this needs is:

• WAPI code (probably in web/filenode.py) to implement a VerifyNodeHandler class, which renders something sensible, and accepts a t=check and/or repair command to be delivered to the verifiernode (and renders the results)
• a clause in web/directory.py make_handler_for() to create these VerifyNodeHandlers when the right sort of URI is provided

[amontero]

Would be fixing this for immutable files worth opening a (hopefully easier) separate ticket? It might even make it more likely to get into 1.11 milestone, perhaps.

[daira]

No new tickets are being added into the 1.11 milestone at this point; the release is already quite late.

It might make sense to split this ticket into immutable and mutable cases, but let's wait until someone volunteers to do the work, so that they can decide whether to do those cases separately or together.

[warner]

Milestone renamed

[warner]

renaming milestone

[exarkun]

Moving open issues out of closed milestones.

[meejah]

Ticket retargeted after milestone closed