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

zooko commented

2009-01-06 18:33:49 +00:00

Owner

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.

tahoe-lafs added the

labels 2009-01-06 18:33:49 +00:00

tahoe-lafs added this to the undecided milestone 2009-01-06 18:33:49 +00:00

warner commented

2009-01-06 19:23:36 +00:00

Author

Owner

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.

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 commented

2009-01-22 23:49:24 +00:00

Author

Owner

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

tahoe-lafs changed title from ~~frontend: check/verify/repair doesn't need the decryption key~~ to frontend: immutable check/verify/repair doesn't need the decryption key

2009-01-22 23:50:34 +00:00

warner commented

2009-01-23 00:34:27 +00:00

Author

Owner

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.

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.

tahoe-lafs added

code-frontend-web

and removed

code-frontend

labels 2010-02-11 01:02:56 +00:00

tahoe-lafs modified the milestone from undecided to 1.7.0

2010-02-11 01:14:27 +00:00

tahoe-lafs changed title from ~~frontend: immutable check/verify/repair doesn't need the decryption key~~ to make immutable check/verify/repair and mutable check/verify work given only a verify cap

2010-02-11 01:15:59 +00:00

tahoe-lafs added

defect

and removed

enhancement

labels 2010-02-11 01:16:41 +00:00

davidsarah commented

2010-02-11 01:19:12 +00:00

Author

Owner

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

davidsarah commented

2010-02-11 04:48:01 +00:00

Author

Owner

#578 was a duplicate.

tahoe-lafs modified the milestone from 1.7.0 to soon

2010-05-17 02:18:52 +00:00

davidsarah commented

2011-10-18 19:02:56 +00:00

Author

Owner

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.

tahoe-lafs modified the milestone from soon to 1.10.0

2011-10-18 19:02:56 +00:00

warner commented

2013-04-30 22:07:58 +00:00

Author

Owner

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

FYI, `nodemaker.py` already knows how to create immutable verifier nodes, which have both `check()` and `check_and_repair()` methods. My untested [mutable-verifiernode](https://github.com/warner/tahoe-lafs/tree/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 `VerifyNodeHandler`s when the right sort of URI is provided

tahoe-lafs modified the milestone from 1.11.0 to 1.12.0

2013-08-13 22:51:28 +00:00

amontero commented

2013-12-23 22:01:16 +00:00

Author

Owner

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 commented

2013-12-26 21:03:55 +00:00

Author

Owner

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.

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 commented

2016-03-22 05:02:25 +00:00

Author

Owner

Milestone renamed

tahoe-lafs modified the milestone from 1.12.0 to 1.13.0

2016-03-22 05:02:25 +00:00

warner commented

2016-06-28 18:17:14 +00:00

Author

Owner

renaming milestone

tahoe-lafs modified the milestone from 1.13.0 to 1.14.0

2016-06-28 18:17:14 +00:00

exarkun commented

2020-06-30 14:45:13 +00:00

Author

Owner

Moving open issues out of closed milestones.

tahoe-lafs modified the milestone from 1.14.0 to 1.15.0

2020-06-30 14:45:13 +00:00

meejah commented

2021-03-30 18:40:19 +00:00

Author

Owner

Ticket retargeted after milestone closed

tahoe-lafs modified the milestone from 1.15.0 to soon

2021-03-30 18:40:19 +00:00

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