#568 new defect

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

Reported by: zooko Owned by: daira
Priority: major Milestone: soon
Component: code-frontend-web Version: 1.2.0
Keywords: confidentiality verify repair usability tahoe-check wui anti-censorship excess-authority Cc: leif@…
Launchpad Bug:

Description (last modified by 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.

Change History (27)

comment:1 Changed at 2009-01-06T19:23:36Z by 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.

comment:2 Changed at 2009-01-22T23:49:24Z by zooko

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

comment:3 Changed at 2009-01-22T23:50:34Z by warner

  • Description modified (diff)
  • Summary changed from frontend: check/verify/repair doesn't need the decryption key to frontend: immutable check/verify/repair doesn't need the decryption key

comment:4 Changed at 2009-01-23T00:34:27Z by 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.

comment:5 Changed at 2010-02-11T01:02:56Z by davidsarah

  • Component changed from code-frontend to code-frontend-web
  • Keywords confidentiality verify repair added

comment:6 Changed at 2010-02-11T01:14:27Z by davidsarah

  • Milestone changed from undecided to 1.7.0

comment:7 Changed at 2010-02-11T01:15:59Z by davidsarah

  • Summary changed 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

comment:8 Changed at 2010-02-11T01:16:41Z by davidsarah

  • Type changed from enhancement to defect

comment:9 Changed at 2010-02-11T01:19:12Z by davidsarah

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

comment:10 Changed at 2010-02-11T04:47:11Z by davidsarah

  • Keywords usability tahoe-check wui added

comment:11 Changed at 2010-02-11T04:48:01Z by davidsarah

#578 was a duplicate.

comment:12 Changed at 2010-05-17T02:18:52Z by davidsarah

  • Milestone changed from 1.7.0 to soon

comment:13 Changed at 2010-12-16T01:17:47Z by davidsarah

  • Keywords anti-censorship added

comment:14 Changed at 2011-10-18T19:02:56Z by davidsarah

  • Milestone changed from soon to 1.10.0
  • Owner set to davidsarah
  • Status changed from new to assigned

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.

comment:15 Changed at 2011-10-18T19:39:32Z by davidsarah

  • Keywords excess-authority added

comment:16 Changed at 2012-03-04T19:31:47Z by amontero

  • Cc amontero@… added

comment:17 Changed at 2013-04-26T00:54:08Z by leif

  • Cc leif@… added

comment:18 Changed at 2013-04-30T22:07:58Z by 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

comment:19 Changed at 2013-08-13T22:51:28Z by daira

  • Milestone changed from 1.11.0 to 1.12.0

comment:20 Changed at 2013-12-23T22:01:16Z by amontero

  • Cc amontero@… removed

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.

comment:21 Changed at 2013-12-26T21:03:55Z by 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.

Last edited at 2013-12-26T21:04:37Z by daira (previous) (diff)

comment:22 Changed at 2014-02-08T21:28:14Z by zooko

  • Description modified (diff)

comment:23 Changed at 2014-02-09T18:21:19Z by daira

  • Owner changed from davidsarah to daira
  • Status changed from assigned to new

comment:24 Changed at 2016-03-22T05:02:25Z by warner

  • Milestone changed from 1.12.0 to 1.13.0

Milestone renamed

comment:25 Changed at 2016-06-28T18:17:14Z by warner

  • Milestone changed from 1.13.0 to 1.14.0

renaming milestone

comment:26 Changed at 2020-06-30T14:45:13Z by exarkun

  • Milestone changed from 1.14.0 to 1.15.0

Moving open issues out of closed milestones.

comment:27 Changed at 2021-03-30T18:40:19Z by meejah

  • Milestone changed from 1.15.0 to soon

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.