Hi, It's time for helly's birthday present from me (and indirectly, Derick, who did the cp -r) :).
As Johannes requested, pecl/phar has been copied to php-src/ext/phar, development will continue there. I suspect there may need to be some changes at gcov.php.net to keep things running smoothly, so this is a heads up message. At this point, phar is ready for the big question: enable by default or not. My benchmarking shows no detectable difference in speed between ext/phar enabled and ext/phar disabled for regular applications, but I would love some confirmation on this. In addition, I just released phar 2.0.0b1 through pecl. Full documentation is available through http://php.net/phar of the latest API. Changes from the last update I sent to internals: * code coverage is pushing 80%, up from about 63% * small performance increases * many, many small and some large bugs fixed * compression/conversion API completely re-worked * lots of other improvements detailed in the manual * 373 regression/unit tests * filename requirements completely rewritten to allow processing things like openoffice odt zip files * full API mirroring of ext/zip, so phar can be easily used by developers used to this API * phar.extract_list removed as obsolete I benchmarked phpMyAdmin in/out of phar, and got 17 req/sec with phar, and 28 req/sec without phar using APC. I also ran a compressed phar, and got 6.62 req/sec, so compression is a significant performance hit. There is obvious room for improvement of performance, and this is going to be a major focus moving forward, as correctness is nearly complete (there are still a few lines of code that are testable, mostly extreme edge cases), and documentation is nearly complete. Another area of focus will be tutorials in the manual on how to create phars, usability tips, and performance information for comparing the formats. At this point, phar's API is "slushy" in the sense that I would like to freeze it where it is unless we've completely missed the boat on something. I would like a full review from interested parties, and I'd also like to openly call for security review of the code. I have spent a lot of time trying to think of bad guy stuff that could be done with phar, and thus far have covered things like: * phar.readonly=1 (default) cannot be disabled except in system php.ini (ini_set fails), and means that executable phar archives cannot be modified by any PHP process. * aliases cannot contain any path separators or : or ; * tar/zip-based archives can't be magically made into phar archives simply by renaming them, as they won't contain the executable stub necessary to run them * open_basedir/safemode checks are in place every time an external path is accessed - I particularly need checking of this constraint, as I am relatively unfamiliar with either system. I've also checked for every buffer overflow/invalid read that I could find, using safe functions wherever possible, and carefully checking the few uses of strcat and company. Valgrind reports no leaks/problems (except in libz, which is an external library used by zlib compression) in 2.0.0b1. In spite of my paranoia and exhaustive attempts to kill any potential security issues, I don't claim to be any kind of security expert, so any and all scrutiny of phar on this front is greatly appreciated. Thanks to all who have contributed, particularly Marcus, Steph, Lars, and the others who chimed in with ideas on the list. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
