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 [EMAIL PROTECTED], 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
