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

[greear at cyberhighway.net]

On Mon, 30 Nov 1998, J C Lawrence wrote:

> 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.

You don't have to give anyone an account on your machine.  (I think you
know this, just pointing it out..)  You just map their account to the
cvs-user account.

My CVSROOT/passwd file looks something like:

ben:PaSsWd:cvs_user
...

In the above example, there is no need to create the user 'ben', and there
is no reason that the end user should know cvs_user's password.
Using this, other than the cvs commands, I'm not sure if you really can
get into the box.  Of course, haven't tried too hard or read extensively
on it...

> #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.

Yep, gonna have to get cozy with the CVS commands...

> > 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.

Gonna have to look this up...  I remember installing it with my latest RH
5.2, so I know it's on here somewhere :)

Ben

Ben Greear (greear at cyberhighway.net)  http://www.primenet.com/~greear 
Author of ScryMUD:  mud.primenet.com 4444
http://www.primenet.com/~greear/ScryMUD/scry.html