Re: [PHP-DEV] CVS Account Request From: Zeev Suraski (zeev <email protected>)
Date: 11/15/00

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 <email protected>>
CTO, Zend Technologies Ltd.  http://www.zend.com/

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