RE : Extending include path to support stream wrappers

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. > 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 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. 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...