On Wed, Mar 06, 2002 at 11:36:50AM -0600, Ari Novikoff <[EMAIL PROTECTED]> wrote:
> >
> > Essentially, the working fix is in CVS for PHP 4.2.0, but we can't
> > have it until they decide to release 4.2.0. Have I mentioned how much
> > I love PHP? :-)
>
> Well, for what it's worth, PHP is fairly slick... I just see hints of M$ in
> quick releases... i.e. "Get the product out. We'll worry about patching it
> later."
What follows is personal opinion, not Mitel opinion:
PHP is slick by accident. I developed heavily in PHP and sysadminned
machines whose purpose in life was to provide PHP-enabled webspace in
a previous job, and it's sheer luck that it works as well as it does.
It's part "we'll worry about patching it later", but it's also a large
part "we know there will be problems, but we don't know what they
are".
PHP is put together by a *very* loosely associated group of developers
who don't talk to each other nearly enough to design a coherent
language. (Compare the MySQL and Postgres functions, for instance.)
There's no language specification, and the documentation is
descriptive rather than prescriptive, so you occasionally encounter
instances where a bug report is met with "We'll change the
documentation so that it isn't a bug anymore".
There's no test suite at all, and specifically there's no regression
testing, so new versions of PHP tend to be, in the words of a
coworker, "New bugs for old! New bugs for old!". Consider PHP 4.0.0,
and 4.0.2, 4.0.4 without patches, and 4.0.5 to a lesser extent -- they
were all essentially paper-bag releases. PHP is too big now to test
unsystematically, but there's no evidence of any systematic testing at
all.
When you think about how PHP started out, as a quick hack that was
only a few levels above SSI, you can see how those procedures might
have been acceptable -- but their development process has failed to
scale along with the language. I would be very surprised if this was
the only remotely-exploitable buffer overflow in PHP.
> > We're in the process of preparing an update which uses our own patch
> > instead of the broken PHP.net patch.
> >
>
> What versions of PHP will that "patch" um... patch? ;-)
The update will contain PHP 4.0.6.
> SME 5.1 ships with what... 4.07? I wonder how many people u/g'd to 4.1.1...
5.1.2 ships with 4.0.4pl1.
We can't support unsupported upgrades -- that's why we call them
that. :-) I expect that we'll release the patch itself to devinfo; if
nothing else, it will be in the source RPM once prepared and released.
-Rich
--
------------------------------ Rich Lafferty ---------------------------
Technical Support Engineer, Network Server Solutions Group
Mitel Networks, Ottawa, ON (613) 751-4404
---------------------------- [EMAIL PROTECTED] ------------------------
--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
