On Tue, May 12, 2015 at 5:05 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:
> On 5/12/2015 3:38 PM, Warren Young wrote: > > The OP said that each of his clients has artifacts in the repository > > that can’t be shared with other sub-sections of the repository, for > > unspecified reasons. He also talked about a shared code base. That’s > > an N+1 situation. > > Let me make a correction here. I am not the OP. That would be Abilio > Marques. I amplified his points to show that there is some interest in > a way to add some finer-grained protection to Fossil. In my view, the > scripting mechanism may be the way to do it so the specifics of the > implementation are given over to the administrator. > > The "unspecified" reasons are ITAR regulations and the like. They don't > have to make sense because they flow down from government. I would > prefer to not discuss them further. drh and I had a private > conversation on this subject several years ago. > This is more of a generic reply to the thread rather than a specific comment on a particular recent entry. While I agree that there is certainly utility in finer grained permissions, the biggest problem I see is enforcing those technical constraints in a DVCS. Even if we accept as a given that it would not be too difficult to build in scripting logic that could ensure people do not commit to particular threads (or do any of the other fine grained things that have been discussed), the difficult part comes in the sync, since they only deal with artifacts. Once someone clones the repo, they have full access to that copy to do with as they please. To make finer grain permissions ultimately useful: 1. The initial clone would have to include not just the artifacts but some minimal subset of configuration data to ensure the user can't violate policies. 2. Disallow the user from making changes in the clone that would disable the configuration data from step 1. 3. Disallow / report to the user any violations while performing local only commands. 3. Disallow / report on any push or sync that results in violations. None of these are impossible obstacles to overcome, but taken together as a whole they do mean there is a significant amount of work to be done to ensure policies are enforced, because the first time a policy is not enforced for any reason at all, people will cry bug. From that point of view I can appreciate why people are hesitant to try to implement something like this. If fossil were a CVCS like svn (or could be configured for a similar use case), it would be easier to enforce these types of permissions. -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
