Re: [PHP-DEV] CVS Account Request From: Ron Chmara (ron <email protected>)
Date: 11/15/00

Sterling Hughes wrote:
> At 10:36 PM 11/15/2000 +0200, Zeev Suraski wrote:
> >Why do you need CVS access then?
> PHP documentation, PHP Website, Closing Bugs and  <email protected> forwarding (I
> know there are one or two in their, some of these people have been in their
> half a year or more and haven't contributed a thing :-),

Problem from a security standpoint: Old accounts lying around are good
targets for a slow brute-force attack. At the least, every once in a while
the inactives should be turned off. We don't even need a system for this,
provided it happens once or twice a year, or when the CVS thread comes up.
:-)

> As Zeev said we should divide the cvs repositories: Websites, Documentation
> and Code.

We also need to keep in mind that dividing the repositories doesn't mean that
somebody who is able, and capable, of working in multiple areas should be
locked out. An errata-editor may need doc/web permissions, but not source.
A doc person might need web and source. A source only person might not
need web or doc. As a doc person, I've had commits to /php4 (doc related),
/phpweb, and /phpdoc, as part of my tasks.... other doc folks have spoken
of this as well. /php4 people need /phpdoc, if they are writing their own
documentation, etc. etc. It's a blurry line, and it's more blurry for
the people who are more active. And while people may be more active in
some areas than others, that shouldn't neccesarrily revoke their ability
to work in a given area. (I can't remember the last time I saw Zeev or
Andi commit docs, should they loose perms to /phpdoc? er....)

> Also I think we should be a little more careful of who we give cvs access
> to on the code root. Right now I could probably get a fake e-mail and such
> from yahoo and obtain a nice ol' cvs account, from which I could then (if I
> was bad) commit some harmful code, which since it would not be a part of
> standard/ or main/ would not be given due attention (especially if it was a
> nice harmful one line bit) and then hurt users who use it.

This, I think, is the core of the issue. It doesn't matter if we split the trees,
try review cycles, _whatever_, if we don't have a level of trust for the parties
involved on CVS.

As far as _establishing_ and _maintaining_ that trust, I like some of the ideas
already posed, and I'll add some additional ones:

1. "Commits to the mailing list(s)" before gaining actual commit access.

2. Establishing a human/personal presence on the list(s) before gaining access.
It should be required that the other members of the CVS teams can at least
rationally converse with you before you can modify their code. A CVS commit
user _must_ follow the dialog on the lists they're in, so they don't commit
blindly, causing an uproar.

3. Anonymous accounts and remailers (yahoo, hotmail, etc.) should _never_ be
allowed commit access. If they aren't of a competancy level to at least have
control of their servers, they shouldn't be able to modify ours.

4. Keep the "back room" (the core list) for negotiating the items of personality,
for *final say* on new CVS accounts.

5. De-activate accounts that have been idle for so long that the core team no
longer recognizes their names, or can remember a recent commit.

6. Communicate off list. This is about creating trust relationships. Get to
know your peers in your given area. Learn their communication patterns, learn
to spot the "real thing" in those requesting commit access.

7. Make the biggest barrier the first one. A lot of the tasks involved in
open source software building require crossing boundaries in your working
areas, and we can (and should) encourage people to grow into as many tasks
as they can do competently.... which means the front door is the most
important one.

8. Sponsoring in new CVS account users. This means that before a person
could get commit access, they've at least earned the trust of one person
who's been here long enough to have an interest in keeping the project
on the right track. There doesn't need to be much in the way of overhead
for this, just somebody willing to say "hey, I've been working with this
guy for a week or two, he seems on the level, his code is okay".

But as far as securing sections of the code/doc/web:
/phpweb folks could compromise the site, /phpdoc folks could do the same, /php4
folks could compromise the code base itself.

Of the 3, the scariest AFAICT (for cracker targets) would be /phpweb simply
because it's the most "public" face of PHP. A code compromise in /php4
would be a bug, followed by a fix no biggie. A website hack is instantly on
slashdot, and maybe even CNN.

> Now while one
> of the reasons many people contribute to PHP is because it is so easy to
> get involved with the development, really most of the commits are only made
> by a handful of people (PHP Group and a 10-20 others, if even). Most of
> the users could simply send patches. Patches make sure the code is qa'ed,
> and then, if the patches are approved (by a committer) then they would be
> committed, after a while if the user is someone who is constantly sending
> (good) patches he would then obtain a cvs account to commit to the code
> repository (documentation could be given less security).

See above arguments about why /phpdoc and /phpweb matters, in some ways
*more* than /php4.

-ROn 

--
Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625
laptop, currently running RedHat 6.1. Your bopping may vary.

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>