Re: CVS Account Request

At 01:47 16/11/2000, Ron Chmara wrote:

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

I agree with that as well (not necessarily because of brute force attacks though). The freeze up time can be very long (a year), but it is a good idea to have it.

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

Right. Frankly, I don't mind losing phpdoc access, if I'll need it - regaining it won't be too problematic. Last time I committed docs was back in 1998, I think :)

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.

Right.

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.

I think that would be problematic to implement, even though it would have been very good if it was.

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.

Hehe, well, I don't really agree with that one... Getting an account at an ISP for a few bucks isn't exactly rocket science...

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

I'm not sure that's such a good idea. I find php-dev to be quite a bit more responsive and versatile, due to its nature - it's a much broader list. I don't think we'd get to situations where we're really uncertain of whether or not we should add someone to the CVS write access.

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.

That would close too many accounts for no good reason :)

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.

That can be good.

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

That's a great way of introducing new people.

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.

A code hack can translate to an exploit affecting tens of thousands of sites on the net. A much bigger CNN piece - almost as big as the piece they'd make if they find Thies's face on Al Gore's site :)

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

I think that they are important, but by far, php4 is the most important one. www.php.net is popular, sure. PHP itself is a hell of a lot more popular, though. Zeev -- Zeev Suraski <zeev@zend.com> CTO, Zend Technologies Ltd. http://www.zend.com/