Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15025
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20050216120637.0afc75f0@localhost>
Date: Wed, 16 Feb 2005 12:56:45 +0200
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: PHPdev <internals@lists.php.net>
In-Reply-To: <4213097F.70002@lerdorf.com>
References: <5.1.0.14.2.20050216084242.056694c0@localhost>
	<5.1.0.14.2.20050215233642.0d784990@localhost>
	<42125B21.30807@bitflux.ch>
	<5.1.0.14.2.20050215182040.056cc500@localhost>
	<59389e98fc650b5609e63cd2de28d863@daleenterprise.com>
	<5.1.0.14.2.20050214162726.03794bd0@localhost>
	<200502150114.j1F1E29s030012@box2.fiddy8.com>
	<4e89b42605021417572dc61cd6@mail.gmail.com>
	<Pine.LNX.4.58.0502142347330.974@miranda.org>
	<59389e98fc650b5609e63cd2de28d863@daleenterprise.com>
	<5.1.0.14.2.20050215182040.056cc500@localhost>
	<5.1.0.14.2.20050215233642.0d784990@localhost>
	<5.1.0.14.2.20050216084242.056694c0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Anyone against requiring libxml2 2.6.x
	for	PHP5.1?
From: zeev@zend.com (Zeev Suraski)

At 10:51 16/02/2005, Rasmus Lerdorf wrote:
>>Inside the php-*.tar.gz packages, it would be very much like sqlite or 
>>PCRE that we bundle today, except it's obviously a bit bigger and more 
>>complex. We'd have to improve the build process to call configure for 
>>this library as a part of the standard configure process.
>>Considering maintenance, which was one of the big downsides of bundling a 
>>library (like PCRE/sqlite), instead of replicating the library in our CVS 
>>at the file level, we'd put it as a closed .tar.gz package, and update 
>>makedist to fetch it and open it into ext/libxml2 or whatever when it 
>>creates packages.  That would mean that:
>>1.  Developers (those who checkout the source tree) would have to open it 
>>on their own, or have PHP use their system libxml2's.
>>2.  Upgrading the version of bundled libxml2 would basically just mean 
>>dropping a new .tar.gz of the new libxml2 version in our CVS, and 
>>makedist will do the rest.
>
>This sounds like an extremely bad idea to me.  We really need to try to 
>avoid rolling large things into PHP like this.  We end up inheriting 
>security fixes and platform specific fixes from these things which could 
>force us into making releases for no reason other than to fix a memory 
>leak or security problem on some weird platform in code we have nothing to 
>do with.  And worse, unless the admin is on the ball, he may not even 
>realize a php update is necessary.  He sees a security problem in libxml2, 
>updates it and his box still gets hacked because he didn't realize PHP 
>brought its own to the party.

You have a point there, we need to think about it.  We'd obviously have to 
provide a solution for this issue, maybe by using the system libxml2 in 
case it's sufficient.  A security conscious admin will always have 
something recent enough for it to be sufficient, and those who don't keep 
up with libxml2 (for whatever reason) will get an out-of-the-box 
experience.  Maybe through some other solution.

>I don't see a huge drawback forcing a dependency on 2.6.x for PHP-5.1. We 
>are still many months away from a production 5.1 release and most 
>distributions are already on that release.

Well, I do, I think it's actually much more important than forcing a fairly 
small subset of the users to update PHP when there's a new security-related 
version of libxml2 coming out (for most of the users, local exploits are of 
no interest, it's mostly interesting to hosting providers, so most libxml2 
issues are not very relevant to the majority of PHP users).

You're making a completely unreasonable assumption, that everyone is 
upgrading their operating systems all the time, when in fact, most 
companies use the 'if it ain't broke, don't fix it' approach, both when it 
comes to libraries and definitely when it comes to operating 
systems.    Many of them (not to say most) are much more likely to install 
a new version of PHP than a new version of the operating system.   Just 
imagine all the servers behind firewalls, the dev servers, which are not 
even kept up to date with security fixes.  We'll start forcing them to be 
on the cutting edge all the time?  We need to find out a reliable way of 
using the latest features of libxml2, which is a core PHP 5 technology, 
without forcing people to do anything beyond upgrading just PHP, and I 
can't think of any practical way other than bundling.

Zeev