bzr serve and access control?

[David Muir]

Josef,

A better solution might be to use two separate repositories. One that 
only holds mechanics, and the other that holds both mechanics and policy.
The first one public, the latter, private.
The mechanics repo would basically be a mirror of the private one with 
the policy bits stripped out. You could automate the process with a 
post_commit hook.

It's a bit like your svn setup, but in reverse. Instead of pulling in 
the mechanics, you're pushing out the mechanics (if I can butcher the 
terms that way ;-).

It would need a bit of work, but the basic idea would be:
1. export to temp
2. strip out policy from temp
3. replace working tree of mechanics with temp
4. commit changes to mechanics
5. clean up

Hope that helps.

Cheers,
David

Josef Wolf wrote:
> On Mon, Feb 01, 2010 at 11:02:50AM +1100, Andrew Cowie wrote:
>
> Thanks for your patience, Andrew!
>
>   
>> On Sat, 2010-01-30 at 15:24 +0100, Josef Wolf wrote: 
>>     
>>> I have repositories that store how my
>>> network and computers are configured, which mail lists I am subscribed to,
>>> phone numbers and addresses of my friends and relatives, my financial and
>>> tax data, keys for my wlan.
>>>       
>> Sure.
>>
>>     
>>> I don't really think this data should be open-source.
>>>       
>> Of course not.
>>
>> The examples you gave are all personal & confidential information. The
>> question I have is why on earth these repositories and the data they
>> contain would be publicly visible at all?
>>     
>
> Just an example: I have a system (similar to cfengine) to automatically
> configure all my systems and keep their configuration up-to.date. When
> installing a new system, I just install a basic default system, checkout
> the configuration repository and type "make install" from there. (I created
> a customized ubuntu-install-cd that does all this with just a couple of
> keystrokes).
>
> This repository is divided into two parts which I call "mechanics" and
> "policy".
>
> The mechanics are more-or-less generic functions/scripts, which provide
> functionality to configure specific subsystems e.g. mechanics/ssh.pl knows
> how to configure ssh. 
>
> The policy specifies details about _how_ to configure it. e.g policy/foo.bar
> specifies how to configure hosts on network foo.bar. Things like authorized
> keys, subscribed lists (which end up in .procmailrc and .muttrc) and all such
> things.
>
> So in summary, "mechanics" are generic methods which I would like other
> people to checkout and even commit to. But "policy" contains sensitive data,
> which should not be accessible to anybody for privacy _and_ for security
> reasons. Whoever can commit to this repository can reconfigure all my
> systems. So I don't feel like I'd give commit access to everybody. And only
> the mechanics part should be readable by other people.
>
> A while ago, I used svn:externals to slurp the mechanics as a subproject
> into the main project tree (that contained the policy). But that created
> more problems than it solved, so eventually I gave up and merged the
> repositories.
>
> I've checked git's subproject functionality to divide the projects again,
> but last time I checked, it was too easy to shoot oneself into the foot
> with git-subproject. Maybe bzr have a solution, but I also need a solution
> for the migration (which can take some time,. I guess).
>
>   
>> In any event, what you were asking for was finer grained user
>> permissions,
>>     
>
> It's not only about finer grained permissions, it's also about not having
> to create user accounts on the server for everybody whom I want to give
> access to one of the repositories.
>
>   
>> but as Ben and I have suggested, there doesn't seem much
>> reason to mix proprietary commercial information and community visible
>> public information *in the same repository*. ie:
>>     
>
> Well, as you see in my example above, it's not always about commercial
> against community. Sometimes it is simply public against privacy/security.
>
>   
>> bzr://www.example.com/bzr/a-very-public-project/ and
>> bzr://www.example.com/bzr/super-secret-except-for-the-name/
>>
>> are separate repositories containing project branch forests with
>> separate access controls - the former perhaps few to none [other than
>> managing committers, say] whereas the latter would have no public access
>> at all, enforced either by file system permissions or web server
>> configuration in the case of http://.
>>
>> Somewhere along the way people seem to have got the idea that all work
>> needs to be in a single repository. [I can only think Apache's singleton
>> subversion server  is to blame, with *All* of the Apache Software
>> Foundation's projects having their code in a single svn repo. Talk about
>> a single point of failure].
>>     
>
> Me too considers that separate projects should have separate repositories.
> But in the above example, it is not really separate projects.
>
>   
>> On the other hand, having branches be
>> smaller than "project" size is also painful, because you have to come up
>> with some mechanism to combine these branches into a project.
>>     
>
> Exactly. I learned that it is very easy to under-estimate the problems that
> mechanisms like svn:externals create.
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100201/176c656a/attachment.htm