Zend Framework Project Teams Need You

Most components and subprojects need volunteers to help with documentation, unit test coverage, code reviews, improving integration with other ZF components, and enhancing architecture and design for the purpose of improving extensibility and ease of use with new components. If you see a subject area or component that interests you, please contact any project members currently associated with the component.

Read the license

The license is BSD-based. It can be found here.
Sign the Contributor License Agreement (CLA)

To contribute source code or documentation at any level (from a few lines, to a patch, to a proposal, to an entirely new component), you must first sign the Contributor License Agreement. This will also give you access to become a developer in the issue tracking system and the developer’s wiki.

CLA signers who also establish a wiki account on this website will be listed on our Project Teams page.
Thus, others will know who to accept code contributions from and who they can work with in drafting proposals.

Subscribe to the appropriate mailing lists

Please join the Zend Framework community by subscribing to the mailing lists that interest you, using the e-mail account you wish to send messages from.

Why PHP?

So, yesterday after reading Ben Ramsey’s post, “Business Case for PHP” I decided to join Stuart Herbert ’s Google Group for developing a business case for PHP.

I am very interested in the outcome of the group’s research:

* Concerns about PHP being open-source
* Security concerns about PHP itself
* Security concerns about software written in PHP
* Performance and scalability
* Finding credible case studies / references for vertical markets
(e.g., insurance, health, finance, etc.)
What do you want to see the business case cover?
Join the, “Why PHP?” – Google Group today!

March To Be Month of PHP Bugs (Bring It On)

During Stefan Esser’s interview with SecurityFocus he announced the upcoming Month of PHP bugs initiative in March.


“The Month of PHP bugs will take place in March 2007. Its goal is to make people and especially the PHP developers aware that bugs in PHP exist. While this sounds obvious for everyone on the outside, it is actually required. PHP has a very bad reputation when it comes to security, which is mostly caused by all the advisories about security holes in PHP applications. For some of the reported bug classes like SQL injection and XSS, this is quite unfair, because those can happen in any language. But Remote File Inclusions, vulnerabilities due to register_globals or other problems within the PHP engine (e.g. zend_hash_del_key_or_index bug) are fully to blame on the PHP language. Unfortunately this kind of thinking is not appreciated by the PHP developers and they continue to claim that PHP is not worse than other languages, and that only badly written PHP applications are the problem. The Month of PHP bugs will show however that a lot of bugs in PHP’s own source code exist.

We will disclose different types of bugs, mainly buffer overflows or double free(/destruction) vulnerabilities, some only local, but some remotely trigger-able (for example, because they are in functions usually exposed to user input). Additionally there are some trivial bypass vulnerabilities in PHP’s own protection features. Only holes within the code shipped with the default distribution of PHP will be disclosed. That means we will not disclose holes in extensions that only exist in PECL, while we are sure that those contain vulnerabilities, too. Most of the holes were previously disclosed to the vendor, but not all.

As a vulnerability reporter you feel kinda puzzled how people among the PHP Security Response Team can claim in public that they do not know about any security vulnerability in PHP, when you disclosed about 20 holes to them in the two weeks before. At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical. Additionally a few of the reported bugs have been known for years among the PHP developers and will most probably never be fixed. In total we have more than 31 bugs to disclose, and therefore there will be days when more than one vulnerability will be disclosed.”

As, Ilia Alshanetsky notes, “It would be interesting to see what issues he discovers, hopefully most of them have already been reported to the PHP Security Team, in which case the upcoming 5.2.1 release will provide a resolution path for affected users.”

He also notes, “I have to look at this as a free security audit of PHP by someone with a clue about security and ultimately, in the long run it will only make PHP better, even if March is going to be rather busy…”.

I couldn’t agree more with Ilia…. I want to see what he really discovers. ;-)

OSCON 2007 Call for Papers

So, I submitted my 90 minute conference session proposal entitled, ” Improving Performance by Profiling PHP Applications”.

I think I am going to focus on Advanced PHP Debugger (APD) for this session. 
George Schlossnagle was kind enough to offer to help explain APD; and the design decision behind it being an analog of C’s gprof or Perl’s Devel::DProf.

Here’s hoping that “The O’Reilly Open Source Convention 2007 Committee O’Reilly Media, Inc.” selects my awesome entry for a 90 minute conference session. ;-)