bzr serve and access control?

[Josef Wolf]

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.