Re: CVS Account Request

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 @php.net 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.