|
From: | Justin Patrin |
Subject: | Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction |
Date: | Fri, 8 Sep 2006 09:10:16 -0700 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |