[MUD-Dev] Re: Ruminations on CVS and developing in the Bazaar

[J C Lawrence]

On Fri, 27 Nov 1998 23:27:02 -0700 (MST) 
Ben Greear<greear at cyberhighway.net> wrote:

> Well, I've consumed almost all of the excellent page on the CVS
> code revision control system:
...

> The problem is trust.  The most likely scenario is that I will
> have never met the ppl who want to help.  How can I trust them?

There are two levels to such trust:

  1) Trust them when accessing your machine (or whoever might gain
access to your machine via the account you give them).

  2) Trust their code changes.

#1 is a bitch, and one I am becoming intimately familiar with under
CVS.  The problem is that any given CVS user with write access to
the repository effectively has the ability to execute arbitrary
programs on your machine without your control.  This is not
something I'm happy with for Kanga.Nu (I'm paranoid).  After a lot
of beating about the bush and messing with SSH, and SSH pipes in
attempt to secure (more) the authentication end of CVS (its pretty
lightweight out of the box) with the idea of using SSH to help limit
the number of people who know or can get the authentication data,
I've finally given up.  SSH1 just can't make port forwarded pipes to
accounts which aren't login/shell accounts (ideally I'd use an
account with /bin/false for a shell, a * password, and whose home
directory is root.root with 0400 permissions) and I'm uncomfortable
with the security of SSH2 as well as its licensing restrictions.

Ergo, for this use, SSH is out of the picture.

Conclusion: Follow *BSD's and BAtMUD's example and set up a chroot
jail for CVS with the accounts that the CVS users map to with the
above russian-style permissions.  This has the huge advantage that
it puts all the onus for security on me as well as making a
reasonably tough nut to crack via CVS.  Still have to do this tho.

#2 is a touchie feelie thing.  I'd recommend a policy of code
reviews, initilly by with yourself as the review, and later with
trusted lieutenants as an additional pool of reviewers.  Then use
nightly builds (if it doesn't build the check-in is bogus) as a
one-way check (I think there was a tool on Freshmeat to track build
errors and their guilty parties), and standard regression tests on
every build as the other-way check.

> So, does that mean watching everything they contribute to make
> sure they aren't screwing something up either on purpose or on
> accident??  

Of course.

> That would seem to go against the benefits of open development....

Notice how many patches Linus refuses...

> I will definately watch the first additions that some other coder
> makes, both to check for careless mistakes and to check for gross
> incompetence...  Maybe that would be enough.  Why would anyone try
> to sabotage it anyway?  That's like reverse-noosphere!

Do *not* allow checkins by anonymous users.  Do use full tracking
with account aliases under CVS to track every change down to the
exact author.  

> What if it's as simple as indentation changes or comment style.

Run Berkely indent as a filter under CVS to post-process all sources
into acceptable formats.  IIRC this is documented in Cederqvist.

> I'm almost anal-retentive in my personal coding style..  Maybe try
> to put down some rules that others are expected to follow or
> else??

1) Document your preferred style in your repository and request that 
all code follow it.

2) Install an indent filter as above, and document that the filter
will be applied to all checkins.

3) Relax.  I too have my own coding style (a pretty linear extension
of basic K&R), but I've had to work with too much other odd and
queerly formatted code to care much any more.

--
J C Lawrence                               Internet: claw at kanga.nu
(Contractor)                              Internet: coder at kanga.nu
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...