LAUPRETRE François (P) wrote:
> Greg Beaver wrote :
>
>
>>Allowing stream wrappers in include_path will open a potentially gigantic
>>security hole, making sure that it is closed will be a huge challenge, and
>>introduce a bit of overhead.
>
>
> I don't understand where the security hole would be. I see the stream wrappers as
> virtual directory trees and I don't see why adding one of their sub-paths in the
> include path would be a security hole. Especially with the allow_url_fopen()
> security. The only difference would be to provide a base for relative URLs when
> there is none possible today (neither the cwd, nor the include path). I agree that
> authorizing stream wrapper paths in chdir() would have security implications but,
> for the include path, I don't understand.
Basically, as of right now, a URL must be explicitly included, which
means something like:
require_once 'PEAR.php';
cannot include anything but a local file. The existence of
allow_url_fopen does not mean that people will only disable it in some
cases, and if stream wrappers are allowed in include_path, this means
that someday a worm will exist that takes advantage of another security
hole to set include_path and then hi-jack the code. This is a security
risk that I am pretty sure is unacceptable considering the marginal
gains it would bring :). To eliminate this risk properly, we would need
to disallow any remote streams (is_url = 1) from being used in
include_path, regardless of the allow_url_fopen setting, which would
slow down parsing of include_path and complicate things.
The solution I've found for pharring things has involved clever use of
str_replace(). I pharred up phpMyAdmin and it works just great using
this technique. This removes the need for an include_path hack.
>>In terms of what choices you have with pecl/phar and libraries, the best way to
>>handle this is to use relative includes (require_once phar://lib.phar/File.php")
>>and have the user either include all the necessary phars in their php script or
>>define an autoload that does it for them, just as they have to do with normal
>>PHP files, or to bundle it all up in 1 phar. In other words, once you split a
>>phar into multiple files, you've lost the primary benefit. Of course, we could
>>move the discussion to pecl-dev if you'd like to talk about features in phar.
>>I find it rather lame that your first response is "phar can't do this" when it
>>is in alpha stage (meaning anything can be changed or added if needed) and has
>>no releases...
>
>
> OK. I apoligize if I looked rude to you. But I tried to understand what features
> (current and future) PHAR provides. And I could not find any documentation. Almost
> nothing in pecl, nothing returned by google. Nothing on features, not even a small
> text to explain the pecl/phar's relation to the PEAR package. When I see in the
> CVS that the project and most files are 4 to 7 months old, and that the only
> available 'documentation' is the C source code, how can you blame me for not
> knowing exactly what your software provides ? I never said that I wanted to create
There may be a language barrier issue here, as I see you are in France
and I am not in France and we are speaking English. I don't blame you
(or anyone) for not knowing things about phar that are not available
(documentation, etc.), all I was saying is that the best way to find out
this information is to ask. Good places to start are the links to the
authors, available at http://pecl.php.net/phar, and conveniently
clickable. Also good is pecl-dev@lists.php.net, where all things pecl
are discussed.
> a new package system just because it is fun. If I had found the information I
> needed about PHAR, I would have tried to enhance it. And it is still possible, of
> course.
I created pecl/phar because it was fun as well as useful, that's not a
bad reason :). Re-inventing the wheel, however, does not seem nearly as
fun. Or as useful.
> Talking about documentation, in order to present more in-depth which features are
> included in the tool I have written, I would be glad if you had a look at
> http://www.tekwire.net/redir.php/phk_doc, chapter 1: Getting started. For the
> rest, it is coming... Take it as a prototype or as feature ideas for PHAR...
I will take a look at your information. Initial glance says you've put
lots of effort into this. As you may have guessed from the age of the
files that you pointed out, neither Marcus nor I have prioritized
pecl/phar over our other pressing needs in the past 4 to 7 months. If
you wish to help with development, we welcome the input, especially if
it ends up improving the code beyond where it is now.
Greg
