Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40941
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error)
Message-ID: <48F17E80.8080103@chiaraquartet.net>
Date: Sat, 11 Oct 2008 23:35:12 -0500
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: Ilia Alshanetsky <ilia@prohost.org>
CC: internals Mailing List <internals@lists.php.net>
References: <48F0E625.9050505@chiaraquartet.net> <A607642D-44BA-4DD7-B468-A54C8B8A8764@prohost.org>
In-Reply-To: <A607642D-44BA-4DD7-B468-A54C8B8A8764@prohost.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] question on how to solve major stream filter design
 flaw
From: greg@chiaraquartet.net (Greg Beaver)

Ilia Alshanetsky wrote:
> Greg,
>
> First of great job on the analysis of the problem. As far as I can
> tell (correct me if I am wrong) the problem lies in extraordinary
> complex use of stream filters, with >2 stacking
> such as phar://zip://bz2:// (for example). Since I'd wager that this
> is not a common use care, I would prefer to refrain from any major
> changes for this for the 5.2 release. Whatever simple solutions we can
> implement such as fix for #1 (which appears to have already been
> committed) are more then welcome, however my call is that #2 and #3
> wait for 5.3, unless a simple and reliable solution is found. 

Hi Ilia,

Actually, I ran into the problem when using a single stream filter on a
file that contained uncompressed data after the compressed data.  When
filling the read buffer, PHP tries to load in an arbitrary number of
bytes.  The bz2 and zlib filters were failing because they would
continue to attempt to process data after the underlying library (libbz2
or libzlib) would tell it that it was done, triggering an error.  The
bug in bz2/zlib was fixed today, but the problem remains - php is
passing in more data to stream filters than it should, as it is never
safe to assume that this is an OK thing to do.  The problem of chaining
filters is an example I doubt anyone has actually tried.  The same
problem exists if one appends a filter to decompress some data, and then
use fseek on the filtered data when not all of the data has been
decompressed (which is actually a typical use case and one I ran into
today).  To be clear, although the example was inside the phar
extension, it uses a file-based stream and stream_filter_append() with
bzip2.decompress stream filter to decompress the contents of a file
within a zip archive, no use of the zip:// stream is done inside the
phar extension.

However, I think it is safe to assume nobody has tried this, as we would
have had a bug report before I ran into it today, so I'm fine with
fixing it in 5.3 unless this new information makes you think it is a
critical addition to 5.2 since it is essentially broken.

Greg