Zend Weekly Summaries Issue #215

December 20, 2004

Uncategorized

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


TLK: CVSROOT / avail
NEW: Call for Papers: International PHP Conference 2005 Spring Edition
NEW: PHP 4.3.10 and 5.0.3
TLK: Downloads cleanup
BUG: foreach() in PHP 4.3.10
REQ: session.serialize_handler
PAT: Don’t forget –prefer-non-pic!


TLK: CVSROOT / avail

Jesper Veggerby Hansen, now one of the newest php.net account holders, wrote a
plaintive note asking whether anyone had managed to get a CVS account opened over
the last couple of months. Alan Knowles forwarded his note to the internals list,
together with a suggestion that the PHP Group should outsource the karma management
of PEAR stuff to one of PEAR Group.

Rasmus Lerdorf, who finds himself responsible for most of the ‘karma management’
on php.net, went through the backlog of applications for CVS access and added a
bunch of new accounts, alongside the following message:

A lot of rejected accounts in this run. Some were clearly bogus,
others were way too vague. We should probably update the tool to let
us provide a rejection comment which in most cases would be, "Which
language project or which PEAR package" do you intend to work on.

He also replied to Alan, saying that he’d love to outsource PEAR account
management, but that the administration tools would need modifying first.

Nuno Lopes, who evidently missed the last round of clearances, wrote suggesting
that the deletion of unused CVS accounts should also be on the agenda. He’d found
that 50% of phpdoc CVS accounts had never been used. Rasmus responded that this was
a lot less critical than the problem of getting new accounts ratified in the first
place. This really does tend to fall on his head, so if Rasmus is busy on a project
and you don’t happen to know anyone who is part of PHP Group, you can find yourself
waiting until his project’s finished before you’re able to commit your contribution.
As he said, having unused accounts sitting around is less of a problem.

Nuno made the point that “there are some guys that use their account like a
free e-mail account redirection
” and accused Rasmus of offering accounts to
anyone who wanted to join, which isn’t actually true. Rasmus tries to verify the
request before creating a new account; this is why it’s generally best to have a
named ‘sponsor’ on a CVS application. It eases the verification process. Nuno then
suggested that there should be a votes system along the lines of the PePR proposal
system in PEAR. You could almost feel the rest of php.net engaging in a collective
shudder at this point, and Rasmus was quick to tag it as ‘work for the sake of
work’.

Olivier Hill made the point that unused accounts could be a security risk, but
noted that it would be difficult for an account holder to do much harm. He also
noted that there were some people that had been given php.net accounts purely so
that they could help maintain the user notes in the manual – these individuals will
never show up in any CVS-based statistics, because they don’t touch CVS itself.
Rasmus backed him; some have accounts but no karma, and others have accounts with
karma (e.g. for the phpdoc module) which they may or may not actively use. He added
that some translation teams consist of a small army of people who don’t do their own
commits; their work is checked by their editorial team, who take responsibility for
the CVS commits for the entire group. Those translators have CVS accounts, and may
also be working on notes maintenance. Trimming the account space is not a trivial
task:


The last time I did it I used a combination of checking the cvs logs
for commits from accounts issued more than a year beforehand and
adding everyone who had never committed anything to a list. Then I
sent an email to everyone on the list asking them to confirm their
accounts and to update their account note to indicate what they were
using their account for. After a few weeks I then deleted everyone I
hadn't heard from and people who didn't provide a decent reason for
keeping their account.

It's probably time to do another such run.

Olivier agreed that the voting system was a bad idea, both because it would
create more work for no good reason and because it relies on the concept of proof.
He also felt that further restrictions on new accounts would be an unwelcome
move.

Sean Coates came up with some evidence
[dead link] that many – but not all – active notes maintainers do in fact use their
karmic CVS accounts.

Andi Gutmans agreed with the original premise of the thread, that PHP Group
should distribute the karma management load and allow sub-groups to handle the
various incoming account requests. He felt that this would allow php.net to be both
much more responsive and more selective. However, this would need to be backed by a
better administration tool than we currently have.

Wez Furlong agreed that having designated ‘karma crews’ for the sub-projects
would be a better approach than the current system. He felt that the biggest hurdle
in designing a new karma-granting interface on masterweb was that it resides on a
different box to CVS; the rest should be trivial.

Short version: A long-overdue cleanup on the karma-granting front is
coming.


NEW: Call for Papers: International PHP Conference 2005 Spring
Edition

Frank Stepan of the Software & Support Verlag sent a Call for Papers to the
internals list at the beginning of the week. The Amsterdam conference will be held
on May 2nd (pre-conference lectures), May 3rd and May 4th, and the streams are as
follows:

  • General PHP
  • PHP & Business/Integration
  • PHP & Databases
  • PHP Design
  • PHP Extensions
  • PHP & XML
  • PHP-GTK

Proposals for two 75-minute talks (per speaker) in these subject areas should be
submitted before January
7th. Speakers’ travel expenses and lodging will be covered, plus of course you get
to attend the rest of the conference and meet up with everybody from the European
end of PHP development.

Short version: Fresh blood required, please do apply.


NEW: PHP 4.3.10 and 5.0.3

Ilia Alshanetsky, as Release Master for the 4.3 series, had the unenviable task
of announcing an unusual dual-branch release on 15th December. His release message
is reprinted here in full:

PHP Development Team would like to announce the immediate release of
PHP 4.3.10 and 5.0.3. These are maintenance releases that in addition
to non-critical bug fixes address several very serious security issues.

These include the following:

* CAN-2004-1018 - shmop_write() out of bounds memory write access
* CAN-2004-1018 - integer overflow/underflow in pack() and unpack()
  functions
* CAN-2004-1019 - possible information disclosure, double free and
  negative reference index array underflow in deserialization code
* CAN-2004-1020 - addslashes not escaping  correctly
* CAN-2004-1063 - safe_mode execution directory bypass
* CAN-2004-1064 - arbitrary file access through path truncation
* CAN-2004-1065 - exif_read_data() overflow on long sectionname
* magic_quotes_gpc could lead to one level directory traversal with
  file uploads

All users of PHP are strongly encouraged to upgrade to one of these
releases as soon as possible.

Aside from the above mentioned issues the releases include the
following important fixes:

* Possible crash inside ftp_get()
* get_current_user() crashes on Windows
* Possible crash in ctype_digit on large numbers
* Crash when parsing ?getvariable[][
* Possible crash in the curl_getinfo() function
* Double free when openssl_csr_new fails
* Crash when using unknown/unsupported session.save_handler and/or
  session.serialize_handler
* Prevent infinite recursion in url redirection
* Ensure that temporary files created by GD are removed
* Crash in fgetcsv() with negative length. (PHP 4 only)
* Improved performance of the foreach() construct. (PHP 4 only)
* Improved number handling on non-English locales

PHP Development Team would like to thank all the people who have
identified the security faults in PHP and helped us to address them.

Alan wrote a note to say that the CAN references were broken and gave
a useful link
so that the security bug information could be viewed.

Short version: Yep, we all kept this quiet… for obvious reasons.


TLK: Downloads cleanup

Gabor Hojtsy, the editor of the PHP manual, asked if the old distributions and
patchfiles sitting on phpweb could possibly be removed. Some, but not all, items
there were available in the PHP museum anyway. Removing the older distros would lead
to less load on the CVS server when people check out phpweb, and less load on the
rsync server for those setting up private mirrors.

Ilia agreed; he saw no reason to keep anything older than three version points in
the current distributions folder. Andi went further; he’d keep the current version
and perhaps the most recent before that, and shift the rest to the PHP museum.

Gabor made the point that the big patches weren’t currently available through the
museum.

Short version: It could be possible to do a phpweb checkout over dialup
soon.


BUG: foreach() in PHP 4.3.10

Jeremy Johnstone wrote in less than 24 hours after the dual security fix release
to highlight a bug
report
against 4.3.10, saying that foreach() wasn’t working
properly and that it was breaking a large number of scripts.

A few minutes later he sent in an update; this was, he said, a Zend Optimizer
issue. There would need to be an announcement on www.php.net‘s
homepage stating that if you upgraded to PHP 4.3.10 you should also upgrade the Zend Optimizer.

Derick Rethans retorted that this was not an internals issue, but a Zend
Optimizer bug. Edin Kadribasic wrote much the same, but concurred with Jeremy that
there should be a warning on the download page at least. Jeremy pointed out that no
previous minor point release of PHP had ever broken like this due to a Zend
extension not being upgraded. “With statements like ‘several very serious
security issues’ on the homepage, many are going to be quick to upgrade…

Edin took his point and added a warning to the download page.

Off-list investigation of the issue uncovered a series of small lapses that had
led to ‘the foreach() bug’. Derick backported a patch to speed up
foreach that Marcus Börger had created for Zend Engine 2/PHP 5,
back in September. Nobody saw a clear
reason for this not to go into Zend Engine 1/PHP 4 at the time, and there was no
negative feedback over it once the usual teething problems with the win32 build
system had been quelled. However, according to Stas Malychev at Zend, that patch
actually broke binary compatibility, and the API number should have been ‘bumped’ to
signal the fact.

The Zend Optimizer stopped working with PHP 4 HEAD at that point, and the Zend
software development team simply fixed it and released a version that would
work with the latest CVS version of PHP 4.3.*, muttering amongst themselves about
the broken binary compatibility – but sadly not to Ilia, the Release Master
concerned, who remained blissfully unaware of it.

This didn’t become a huge problem until we had the PHP security release, which
(obviously) received a lot of publicity. Every man and his dog went to download PHP
4.3.10 as a consequence, and suddenly there’s a broken foreach() for
all those men and dogs that don’t upgrade as a matter of course and that happen to
use the Zend Optimizer.

There are quite a few of those.

So no, it’s not a Zend Optimizer bug. But nobody came out of this episode
smelling particularly rosy, and there are very evident lessons to be learned from it.

Short version: It’s good to talk.


REQ: session.serialize_handler

Richard Thomas wrote in asking if session.serialize_handler couldn’t
be made part of the session.save_handler ini option, thereby allowing
users to register their own functions for it. He gave the example that someone using
a database to store session information might want to update session variables one
at a time in order to reduce the amount of data being passed around. Currently this
can only be achieved by manually unserializing the data on writes and serializing it
on reads.

Short version: Just a thought.


PAT: Don’t forget –prefer-non-pic!

The saga of Wotjek Maler’s patch continues, with Andi requesting the diff sent to
him as an attachment and including do_alloca(),
free_alloca() calls (huh?). Andi did at least promise that this patch
will eventually make it into CVS; it has therefore been removed from "/article/1432">the PAT directory now.

Rasmus’ patch, giving the --prefer-non-pic build option on platforms
that support that possibility, was somehow forgotten during the flood of security
fixes prior to this weeks’ releases. Ilia does, however, intend to add it to PHP
4.3.11.

Jesse Binam submitted his new functions for the ftp extension,
ftp_get_resp() and ftp_get_conv(), for review. The general
consensus was that they need a little more work before they can be accepted, with
both Wez and Andi advising Jesse to look into the smart_str API to help
manage buffer sizing and memory allocation.

Short version: Nothing new for the PAT directory
this week.

Comments are closed.