#833: reject mutable children when *reading* an immutable dirnode
-------------------------------------------------------------+--------------
Reporter: warner | Owner:
davidsarah
Type: defect | Status:
assigned
Priority: critical | Milestone:
1.6.0
Component: code-dirnodes | Version:
1.5.0
Keywords: integrity forward-compatibility confidentiality | Launchpad_bug:
-------------------------------------------------------------+--------------
Comment(by davidsarah):
Replying to [comment:32 davidsarah]:
> Replying to [comment:30 zooko]:
> > Replying to [comment:28 davidsarah]:
> > > If unknown caps (i.e. unknown to the webapi server) are allowed to
be returned in directory reads, then the webapi can't ensure this property
for such caps. I'm leaning toward just documenting that.
> >
> > Should the webapi server tag such caps with something like {{{unk.}}}
so that the fact that they came from a context where this property
couldn't be verified is not lost?
>
> What would the webapi client do with that fact? {{{imm.}}} and {{{ro.}}}
are associated with specific conformance requirements, but {{{unk.}}}
wouldn't be -- it would just be a hint that the webapi client shouldn't
assume something. It is easier to document that it shouldn't ever make
that assumption. (Note that a webapi client could always decode the caps
and check that they are consistent.)
... although it should probably avoid decoding caps since that is the
webapi server's responsibility. Which reminds me: we don't seem to have
either a webapi operation or a CLI command to diminish a cap.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/833#comment:33>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
_______________________________________________
tahoe-dev mailing list
tahoe-dev@allmydata.org
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
