Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction

[Justin Patrin]

On 9/7/06, Zack Weinberg <address@hidden> wrote:
> On 9/7/06, Bruce Stephens <address@hidden> wrote:
> > "Justin Patrin" <address@hidden> writes:
> > That would be the netsync way to do it, yes.  Alternatively, the
> > server could permit these changes, and then you apply the trust
> > decisions when doing "update", "merge", etc.  Just as monotone works
> > now (with the get_revision_cert_trust hook, mostly, but also the
> > testsuite one, I guess).
> >
> > Both seem doable.  I guess the testing on use way would more easily
> > allow changing policy: you'd have a reasonably fixed database, and the
> > various access decisions could change as the policy changed.
>
> I just want to chime in with a scenario where you really want the
> check to happen on netsync: a project may want to ensure that its
> official server's database contains only data that they are sure they
> have permission to distribute, even in un-blessed revisions.
> Otherwise, a bunch of warez d00dz could perfectly well piggyback on
> someone's project server -- they don't care that their illicit
> revisions are not considered part of the project, they can still get
> 'em.  And I think the project would still be in legal trouble.

There are less script-kiddie possibilities, too, such as allowing a
developer to continue to submit violations to licensing (possibly even
proprietary code). You won't use it if your trust seed doesn't trust
this developer but *you* are still distributing these revisions. You
might be able to get out of it legally as you're not the comitter, but
I wouldn't want to fight such a battle.

I can also see a sposisbility the other way, though, where you want to
allow someone who you don't trust at the moment for updates and such
to keep comitting so that others who do trust this developer can still
pull these revisions (perhaps they are simply moving in another
direction but you don't want to completely break ties or you share the
host).

Basically what I'm saying. I suppose, is that there need to be
policies/permissions both for updating and for netsync.

(Presumably the netsync permissions could go both ways as well. If I
wanted to continue pulling monotone but didn't want to pull one
developers' revisions I'd like to have this option. Of course this
would likely cause some problems as excluding one active developer
would effectively stop me from pulling anything after that point that
depends on that developers' revisions, but I still think this would be
a useful use-case.)

--
Justin Patrin