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

At 00:59 16/11/2000, Rasmus Lerdorf wrote:
>On Wed, 15 Nov 2000, Zeev Suraski wrote:
>
> > At 00:24 16/11/2000, Rasmus Lerdorf wrote:
> > >Part of the reason the PHP project has been successful is precisely
> > >because the barrier of entry has always been nice and low. This applies
> > >both to the language itself and also to the development of the language.
> > >I can count on one hand the number of times we have had bad commits over
> > >the last 5 years.
> >
> > Your hands must have changed a lot since I last saw you :)
> > There were dozens.
>
>Bad commits being commits that we needed to reverse because they were so
>wrong that they couldn't be fixed. Sure there have been commits that
>broken things. You and I have made dozens of such commits. Nobody writes
>code without bugs. That doesn't mean we shouldn't have cvs access.

I'm talking about commits that were outrageously wrong. I recall quite a
few such commits that Andi caught in the last year. Of course we're all
human, and make mistakes.

The point I'm trying to make is that there's no such thing as absolute
security, ANYWHERE. That doesn't mean we should give up on security
completely, because of that. The right terms here are not absolute, but
relative - there is such a thing as increased security.

> > So, did you find the buffer overflow bug in Onn's fribidi extension?
>
>No I didn't, the commit message is still unread in my inbox due to a heavy
>travel schedule, but chances are I wouldn't have caught it when I got back
>and started chewing through my mailbox anyway. But are you seriously
>suggesting that because he had an overflow in his extension he should not
>have had commit access? Onn works for Zend and Andi vouched for him and
>created his CVS account. Those a pretty good credentials and I don't care
>how much we tighten rules, Onn would still have gotten a CVS account and
>he would still have committed an extension that contained a buffer
>overflow so I don't see how this does anything to prove your point.

Well, his code didn't have a buffer overflow, it was just an example. I
think it's pretty unreasonable that you'd be able to go over the CVS
updates that piled up in your mailbox in any remotely efficient way. It's
not human, and I don't blame you for not doing that. That is why we should
try to reduce the chances of problems occurring there to begin with. You
don't have to wait for the problem to have negative symptoms before you try
to reduce it.

>As long as it can be done without adding extra hurdles for legitimate
>contributions I am fine with it. ACL's make sense. But I am leary about
>any sort of review-then-commit type of approach as per Sterling's
>suggestion. It puts an extra workload on existing contributors and
>introduces delays for potential new contributors.

I think that a startup period for new comers is not a bad idea in
general. It should be a fairly short period, it can be extremely short (a
few days, a couple of weeks at most). If you see patches flowing in from
that guy, and they look ok, it means two things - he's unlikely to be a
hacker, and he's probably in a real need for a CVS account. Today, we have
no clue about these two issues at all, and he's granted a CVS account
almost automatically.

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>