revocable write authority #954

Open
opened 2010-02-15 05:20:59 +00:00 by zooko · 3 comments

As described in [//pipermail/tahoe-dev/2009-June/001995.html], the easiest kind of revocation to implement in a distributed, robust way is also the kind of revocation that I most urgently need: revoke the write-authority embodied in a specific cap.

The way to implement this is to define a special out-of-band symbol (i.e., something unambiguously distinct from file contents) which means "this file has been petrified". That would be a way to take a mutable file and turn it into a petrified file (formerly mutable but now immutable).

As described in [//pipermail/tahoe-dev/2009-June/001995.html], the easiest kind of revocation to implement in a distributed, robust way is also the kind of revocation that I most urgently need: revoke the write-authority embodied in a specific cap. The way to implement this is to define a special out-of-band symbol (i.e., something unambiguously distinct from file contents) which means "this file has been petrified". That would be a way to take a mutable file and turn it into a petrified file (formerly mutable but now immutable).
zooko added the
code-mutable
major
defect
1.6.0
labels 2010-02-15 05:20:59 +00:00
zooko added this to the undecided milestone 2010-02-15 05:20:59 +00:00
zooko modified the milestone from undecided to 1.7.0 2010-02-23 03:13:42 +00:00
Author

This is a requirement of #958 (LAFS 301 Moved Permanently).

This is a requirement of #958 (LAFS 301 Moved Permanently).
Author

Out of time to implement this for v1.7.0. I hope to add it to v1.8.0.

Out of time to implement this for v1.7.0. I hope to add it to v1.8.0.
zooko modified the milestone from 1.7.0 to 1.8.0 2010-05-05 05:42:04 +00:00
Author

Out of time to implement this for v1.8.0. It is a forward-compatibility issue (at least I think so--I'm not sure Brian agrees) so I really do want to get it completed as soon as possible, but we already have a full load of other important issues for v1.8.

Out of time to implement this for v1.8.0. It is a forward-compatibility issue (at least I think so--I'm not sure Brian agrees) so I really do want to get it completed as soon as possible, but we already have a full load of other important issues for v1.8.
zooko modified the milestone from 1.8.0 to soon 2010-07-24 05:41:07 +00:00
zooko added
enhancement
and removed
defect
labels 2011-12-27 20:08:24 +00:00
zooko changed title from revoke write authority to revocable write authority 2012-01-31 17:30:10 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#954
No description provided.