Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension & Abstraction Layer

[Ralf S. Engelschall]

On Tue, Sep 25, 2007, Nathaniel Smith wrote:

> On Mon, Sep 24, 2007 at 07:24:51PM +0200, Ralf S. Engelschall wrote:
> > We're now addressing the problem "How can we ensure that a revision is
> > not stored into the database at all in case an ACL hook determines that
> > one of its certificates break an ACL rule?" the following way:
>
> By the way -- have you considered simply dropping illegal certs?
> This would permit a *much* simpler implementation, but I don't know
> if it would satisfy your requirements.  It would of course allow
> "illegal" files/revisions to take up space in your database, but
> monotone will never actually *do* anything with a revision unless a
> cert tells it to (or a user explicitly requests it, like with -r <full
> rev id>).  If any such "ghost revisions" do accumulate, you can
> garbage collect them by periodically doing a pull into a fresh
> database, and then replacing your old database with the freshly-pulled
> one.

Yes, we have not just considered this but if you look at the patch it
is also implemented. Each Lua hook can return four value: "accept",
"ignore", "rollback:<message>" and "abort:<message>". Currently we
are using mainly "accept" and "rollback:<message>", but the approach
you mentioned is achieved by returning "ignore". Then the cert would
silently be just ignored.

> Note, though, that though mtn will never do anything with such
> certless revisions, it may do stuff with their descendents (if their
> descendents have appropriate certs).  E.g., if I have A -> B -> C, and
> B has no valid branch cert, but A and C both do, then mtn will happily
> say that C is a branch head.  I can't tell from your description if
> that would violate your security goals.

Partly. But it would not hurt very much AFAIK. It certainly could be
acceptable, too. And as I said this is also supported by the NETSYNC Lua
hook extensions we coded.
                                       Ralf S. Engelschall
                                       address@hidden
                                       www.engelschall.com