[Monotone-devel] forbid: a (nicer?) alternative to obliterate

[Lapo Luchini]

Going the full way with the "obliterate" feature, i.e. permanently
delete a file version and recursively spread this deletion like a virus
upon sync, is not certainly a feature we would be comfortable with, as
the would be quite a lot of issues regarding trust ("oh, the remote
server states I should delete this, and who is he to say that? I only
trust about myself").
OTOH we could probably use a strictly local "forbid" feature such as this:
    mtn forbid VERSION
or, more conveniently,
    mtn forbid -r REVISION FILENAME
that would add VERSION to a table of "forbidden versions" and delete it
from the file content table (changing the "base" of the next deltas to
apply on the previous not-forbidden file content).
On sync, any forbidden VERSION received would be silently dropped.
On checkout/update, it should not panic with a missing content but
instead loudly say "File 'xyz' not updated because his content was
forbidden.".

I also have another (debatable) use-case that is not related to legally
encumbered content you are told "from above" you must delete: someone
using monotone and his wonderful binary-content support to help
deploying and updating an installed software (i.e. executables!).
If one specific version of the executable has got a virus, people from
the security team may well decide that is is better to entirely forbid
that content, thus avoiding other people from executing them and thus
infecting their system (and possibly many more executables).

Once policies are here, instead of a "forbidden contents table" it could
certainly be useful (better?) to have a sort of "CRL" for VERSIONs
(only, instead of a "certificate revocation list" it would be a "content
removal list") signed by the very same people that have signed the
policy. After all people can't (and shouldn't) be able to delete your
local content (and you can do read-only backups anyway, if you want, so
that's really pointless) but if you want to work on a project you should
probably accept his policies, including not getting 'em in trouble
because you're committing a new revision containing old forbidden
content with only a whitespace change (you can do that anyway, of
course, but having to accept the CRL as part of the policy itself
doesn't seem too much controversial to me).

What do you think?
What possible problems do you foresee that I didn't think of?
(please think about the "base" strictly local-only "forbidden list" and
the policy-based, and thus distributed, CRL thing separately, on reply,
as they are certainly two very different beasts)

    Lapo

signature.asc
Description: OpenPGP digital signature