Re: [Monotone-devel] Re: Re: Re: How will policy branches work?

[Justin Patrin]

On Feb 6, 2008 7:42 AM, Boris <address@hidden> wrote:
> On Wed, 06 Feb 2008 14:51:27 +0200, Markus Schiltknecht
> <address@hidden> wrote:
>
> > Boris wrote:
> >> It might be possible if policy settings and the list of administrators
> >> are stored in the database. Even if you have a copy of the database the
> >> database knows who the admininistrators are and will prevent others
> >> from changing the policy settings. Of course if administrators
> >
> > Who are 'the administrators' in a distributed setting? I know, this
> > might be very clear in a hierarchically organized company. However, for
> > lots of open source projects, I would consider every single developer as
> > the admin of his repository.
>
> Yes, that's a different scenario. Ideally centralized permission settings
> are optional.
>
> > [...]If the files for these activation components are in the same
> > branch, each revision maintains a hash over their contents. So, if the
> > new co-worker is denied downloading those files, he cannot completely
> > validate the revision. That would clearly speak for splitting those
> > files into its own projects.
> >
> > OTOH, that new co-worker cannot change these files, so monotone could
> > simply skip the hash calculation for those files and reuse the existing
> > hashes from the parent revision. I'm slowly beginning to think, that
> > what you want here, is policy branches in conjunction with partial
> > checkouts (where these activation component files are missing).
>
> The problem is the co-worker shouldn't be allowed to check out the files
> at all. Management doesn't want anyone else except the responsible
> developers to see the source code. That would need to be guaranteed by the
> version control system - easy if it's a centralized one, arguably more
> difficult if it's a distributed one. I don't know if this will ever be
> possible with monotone (I don't even know if such a scenario is supported
> by any other distributed version control sytem) but these are the
> requirements I face. :)
>

I think what you're describing is a false sense of security. If the
"central repository" enforces that certain people can pull certain
files an certain people can't then that doesn't stop someone who has
access sending the files over to someone who doesn't have access. The
only full solution to such a problem would be controlling absolutely
everything, including all hardware and software on the machines which
have access to this info, including any outside access (such as
external devices and network access) and enforcing all of your rules
by brute force.

Hmmm, this sounds like DRM, doesn't it?

<DRM rant>
My point is that enforcing such rules is essentially impossible,
especially with a decentralized system such as monotone. Now, monotone
can help you enforce parts of this but it is always going to be
possible to easily circumvent such restrictions unless you lock all of
the *other* software down on the system. If you do this, of course,
you're going to severely limit the productivity of your workers. I've
see what excessive DRM can do, my father is in the Army. Those systems
are so locked down you can't get anything that is even remotely
non-standard done. Developers always need non-standard tools and need
to use their systems in non-standard ways. Even casual users tend to
hit these restrictions daily.
</DRN rant>

Ok, enough of the rant. As monotone stands now you have at least one
way to enforce your set of rules. Here is what I would suggest. Each
set of code that has different access retsrictions should be in its
own branch. Make it so that these pieces can be built modularly. Don't
propagate between these branches. Set up a seperate mtn serve instance
for each of these sets with different keys allowed to pull and push.

Specifically I think you could have 2 serer instances, one for the
general project and one for the restricted components. In order to
make this as error-free as possible you would need developers to have
a seperate mtn DB for each of the 2 sets to avoid accidental pushing
of restricted code to the unrestricted server and avoid propagation
from one tree to the other.

The only thing that is missing in monotone now to allow you to merge
the 2 DBs would be for each key to have restricted push *and pull*
access to certain branches. The one thing you have to think of here,
though, is that if the history of these components ever touch
(propagation, merge_into_dir, etc), then you may be required to pull
one with the other. There is no way currently that you could stop
someone from getting specific files in a revision without breaking all
of the assurances that monotone gives you.

-- 
Justin Patrin