[PHP-DEV] PHP 5.0?

[Richard Lynch]

Hey there!

I'm hearing rumors that ZE2 release will happen Fall 2002 and that will make
it PHP 5.0, not 4.x...

Any comment, on or off record?...

A book publisher I'm working with kinda needs to know whether to change the
project requirements and release later, or push release "soon" and worry
about 5.0 in 2003, or ...

They do have enough sense to refer to my research (and your potential
answers) as "reading the tea leaves" :-)

I've searched the Dev archives and Zend lists, and even posted back in
March...

I've come up empty on future planning along these lines, and nobody was
willing to go out on a limb back in March :-)

OTOH, maybe these rumors are a *result* of my stupid query back in March :-)

Off-list, off-the-record, and unofficial replies are fine.

THANKS!!!

-- 
Like Music?  http://l-i-e.com/artists.htm


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Release Tea Leaves

[Richard Lynch]

Any Wild Guesses about release dates for PHP 5 and/or Zend Engine 2???

A publisher is worried that the book will be hopelessly obsolete 
before it hits the shelves, rather than the usual obsoleteness... :-^

Thanks in advance, and please cc me.

-- 
Like Music? http://l-i-e.com/artists.htm
My hard drive crashed on April 28th...  Re-send any critical email.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP Future

[Richard Lynch]

First, apologies for two (2!) queries in the past couple weeks from a 
guy who barely can find time to lurk on a thread or two anymore... 
Hope I haven't used up all my brownie points...

Second, I want to thank everybody for their help on the "PHP 
Security" query -- While IPCop (http://ipcop.org) has decided to go 
with Python (more developers on the team know it), I think I opened a 
few minds of people who had only looked at the "body count" on 
Bugtraq et al rather than really checking the facts -- They'll 
probably be using PHP for future projects, even if we "lost" this one 
:-)

I'm working with a Publisher (Wiley, fka Hungry Mind, fka IDG...) on 
a couple PHP books, and have been asked to "read the tea leaves" 
(literally) about:

PHP 4.2.0 ++
PHP 5.0

New Features, Improved Features, Time-line, that sort of thing. 
Something where somebody can "push" for another PHP book on the shelf 
instead of XYZ, with some nice buzz-words and catch-phrases of what 
simply *must* be covered to be on top of the industry :-)  [Okay, I'm 
a programmer, not Marketing...]

I tried the PHP-Dev archives, but searching for "5" and "PHP 5" was, 
um, not particularly useful, as you might imagine.  I'll be digging 
into ChangeLogs for 4.2.0 next, but could use some guidance on what's 
high-level versus typo-fixes.

Obviously, we're not expecting a detailed corporate time-line here 
(hey, *they* were realistic enough to call it "reading tea leaves", 
eh?) but any sort of input on when to best have books hit the shelves 
with coverage of relevant material and suitable Marketable versioning 
on the cover to better promote PHP (and, admittedly, the books I'm 
working on) would be most welcome.

[aside]
Like many industries after the dot-bomb and 9/11, book Publishers are 
severely limiting the number of titles for the this fiscal year, so 
every book is facing a "Justify Your Existence" sort of thing.
[/aside]

Please reply off-list, and I'll summarize late Monday (US Central) 
night.  I'm probably asking at the *worst* possible time in the 
middle of 4.2.0 QA, but our insider at the publisher has to go into a 
meeting Tuesday morning armed with data/stats/info...

PS  If there's some topic in particular, other than your own 
Extension :-), that you think really needs coverage, holler at me. 
If it's your own extension, go ahead and holler, but let me know your 
bias :-) :-) :-)

Please Cc: me if you think of it, though I'll do my part and check 
the archives.

Thanks in advance for any help!
-- 
Got Music? http://l-i-e.com/artists.htm

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] OT? buffer overflow attacks

[Richard Lynch]

PHP is in contention for an XML/RPC server/client system for the 
configuration panel of IPCop (http://ipcop.org) a stand-alone 
firewall project running on stock hardware with a stripped-down 
RedHat Linux.

This project is a fork from the more infamous SmoothWall, without 
the, ahem, project manager's unique personal skills... :-)

The current criteria are:
#1 Security (duh)
#2 Size (small footprint) for RAM and boot floppy distro usage.
#3 Speed (reasonable performance is required)

I know PHP "wins" on #2 and is on par on #3.

A bone of contention is, obviously, the security reputation of PHP.

The team is willing to concede that bad installation accounts for 
most of the problems -- But are still concerned about buffer overflow 
attacks.

I'd love to hear that there are no known buffer overflow attacks in 
PHP core (the Zend Engine) nor in the XML/RPC extension, and both 
have undergone a close-scrutiny code audit by security-experienced 
personnel, preferably somebody with a verifiable reputation in 
security.

I'd be happy to hear that virtually all of the past buffer overflow 
attacks occurred in third-party extensions, and the XML/RPC 
extensions have been largely immune.

I'd be content to find out that PHP is just not the right choice...

There is no problem with running 4.2.0 if that is required to be secure.
-- 
Got Music? http://l-i-e.com/artists.htm

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Richard Lynch]

Relying on initialization by the system instead of doing it by hand is bad.

What if somebody then includes your file into something else, but has used
that variable, but their final value is usually 0, except when it's not...

Then, your code works for a while and then inexplicably breaks.

Always initialize variables.

--
WARNING [EMAIL PROTECTED] address is an endangered species -- Use
[EMAIL PROTECTED]
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm
- Original Message -
From: Stanislav Malyshev <[EMAIL PROTECTED]>
To: Cynic <[EMAIL PROTECTED]>
Cc: Zeev Suraski <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; PHP Development
<[EMAIL PROTECTED]>
Sent: Friday, August 17, 2001 11:33 AM
Subject: Re: [PHP-QA] Re: PHP-4.0.7RC1


> C>> if('foo' == $x){
> C>>   $secure = true;
> C>> }
> C>> ...
> C>> if($secure){
> C>>   # do sumthing that needs authentication
> C>> }
> C>>
> C>> This will happily run in E_ALL &~ E_NOTICE whether $x == 'foo' or not.
> C>> Attacker can then inject $secure in the query string, and it'll apply
> C>> whether or not $x == 'foo'. This will be caught with error_reporting
> C>> E_ALL.
>
> That's entirely different issue, having nothing to do with notices, but
> with register_globals and mixing internal and user-supplied variables. The
> fact that E_NOTICE may in some situation help you to find it is lucky (or,
> on the second thought, unlucky - it may as well not happen, and you are
> toast with all your belief in notices) coincidence, nothing more.
>
> C>> Yes, average PHP code is full of security or other holes.
>
> That's overbroad statement which is just wrong. I can show you a lot of
> scripts generating a real lot of notices, but having no security hole.
>
> Also, note that fixing notice in the above code in the obvious way -
> changing simple if() to isset and stuff - will shut up your precious
> notice mechanism, while leaving the hole wide open. Is that what you want?
>
> --
> Stanislav Malyshev, Zend Products Engineer
> [EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115
>
>
>
> --
> PHP Quality Assurance Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file

[Richard Lynch]

> >I think PWS on 95/98 looks in the registry...
> Agreed - PWS on these platforms is fundamentally a cut down version of
IIS3.
> I suspect it is possible to have this on NTWS as well, but PWS4 which
comes
> with the NT option pack (same CD as IIS4) certainly looks in the
Metabase -
> though I don't know whether it also checks the registry. In any event,
even
> if it does, it will only be for legacy reasons, so I think we can ignore
it.

If you ignore it, you'll continue the problem:  People attempt to install
PHP with PWS on Win95/98 and get frustrated, and have to dig all over
creation to find install instructions that should have been in the PHP
release.

--
WARNING [EMAIL PROTECTED] address is an endangered species -- Use
[EMAIL PROTECTED]
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

[Richard Lynch]

> On Thu, 03 May 2001, Andi Gutmans wrote:
> > Yeah but I'm afraid it'll make scripts be written on behavior which
> > shouldn't be counted on.
> > Maybe in future versions of Zend $array['foo'] won't be defined. There
are
> > certain situations where I think it was impossible to not define it so
it
> > was defined with NULL meaning it's not defined.
>
> Um, but some db extensions return NULL values as part of the array, so
> if column 'foo' is NULL in the db, you'd want the result array to have
> NULL under key 'foo' - it just won't do to have that column be missing.

Um, lots of people use isset($row['foo]) to detect NULL in the database...

Are you going to change that behaviour?

Don't.

If the column is missing, they screwed up their SQL, which is not within the
pervue of PHP to fix in the first place...

--
WARNING [EMAIL PROTECTED] address is not working -- Use [EMAIL PROTECTED]
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6

[Richard Lynch]

How exactly would you define success/failure of the RC?...

I mean, if it crashes, you can probably catch that, but what if the output
is just incorrect?

You're back to the problem of only a pre-determined (and very limited)
validation suite can really use this, I think...

Or am I just being obtuse and difficult?

What might be more realistic would be to "fork" the request to an invisible
(to the end user) testing machine and real machine.

Then, the outputs of the two can be compared, and an error report of some
kind generated for any differences.

Ideally, the production output would be sent on its way without any "delay"
waiting for the testing machine to
respond/fail/explode-in-a-burst-of-flames.

There is some overhead, of course, but I *think* this is a more feasible
design, possibly even "doable"...

--
WARNING [EMAIL PROTECTED] address is not working -- Use [EMAIL PROTECTED]
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm
- Original Message -
From: Zak Greant <[EMAIL PROTECTED]>
To: James Moore <[EMAIL PROTECTED]>; Andi Gutmans <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, May 02, 2001 2:16 PM
Subject: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6


> Andi wrote:
> [snip]
> > That was really a big disappointment as people did such a good job on
the
> > release cycle IMO.
> > No doubt it shouldn't have slipped in.
> > And if it doesn't get fixed soon we should revert to the old version of
> the
> > COM module.
>
> How much testing is the QA team actually doing?  I would suspect that
> the
> majority of the QA team follows the same slack process that I follow.
>
> 1.) build the latest release
> 2.) make test
> 3.) look at phpinfo()
> 4.) see what happens to a few scripts
>
> Am I right? :)
>
> We should be testing the RC's against large bodies of working
> code that real users are using. This is tough to do - no one wants to
> break a working site.
>
> How difficult (and useful) would it be for us to have a system like
> the one describe below.
>
> The standard PHP SAPIs and CGI executable are replaced by shell that
> maintains environment data and passes it to an RC.  The RC attempts
> to handle the request.  If it fails, the shell passes the same request
> is passed to a stable version of PHP, and the failure is logged,
> along with the environment data, etc...
>
> The user request may be slowed, but is still served.  The shell
> could include threshold settings so that we stop passing requests
> known to break the RC after a certain number of requests...
>
> By co-operating with various site owners, we could get the RCs into
> environments where they server millions of hits in a day in a broad
> range of situations.
>
> Anyone think that this blueskying is useful or possible?
>
> --zak
>
>
> --
> PHP Quality Assurance Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)

[Richard Lynch]

> The question is, if you think people will actually download the RC in
order
> to test it (as opposed to using it) - why won't they join the QA team?

Because they have enough time to make sure their software still works with
the RC, but not enough time to wade through all the QA emails. :-)

Most likely, though, the cost/benefit ratio of mass distribution of the RCs
is borderline -- And throwing a few more resources at the QA team (eg Win
binaries) will be far more effective.

There will *always* be some bugs that only get found by mass testing.  The
COM bug should have been caught by a QA team member, and you've identified
why not.

:-) :-) :-) Suggested Compromise Ultimatum:  Windows binaries and Zend test
machine before 4.0.6RC1, or post RC announcement to the masses.  This should
goad us (okay, you) into having the process in place or suffering the
consequences :-) :-) :-)

--
WARNING [EMAIL PROTECTED] address is not working -- Use [EMAIL PROTECTED]
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] What to do about 4.0.5

[Richard Lynch]

Maybe I'm just a Luddite, but...

Does *any* browser actually compose URLs with ; yet?

If nobody's using the standard, why rush to implement?

--
Visit the Zend Store at http://www.zend.com/store/
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm
- Original Message -
From: Andi Gutmans <[EMAIL PROTECTED]>
To: php-dev mailinglist <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, April 04, 2001 10:35 AM
Subject: [PHP-QA] What to do about 4.0.5


> OK guys,
>
> I feel VERY uncomfortable releasing 4.0.5 with this arg_separators
problem.
> Let's brainstorm and try to think of a nice, clean and constructive way of
> solving this problem. Let's try to ditch the "screw the user because he
> didn't read RFC foo.bar approach :)
> The issue is with the arg_separator of incoming URL's. If we think of a
> nice solution we should probably make it look&feel similar to the solution
> we will have with URL's which are created.
>
> Ideas? Thoughts?
>
> Andi
>
>
> --
> PHP Quality Assurance Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming

[Richard Lynch]

> It HAS to be time for a big tidy up, as it is clearly impossible to 'do
the
> right thing' under current circumstances.

Problem is, what you see as "untidy" programmers with a background in other
languages and software packages see as "convenient". :-)

For every "newbie" it helps to have consistent
every_word_gets_an_underscore, you quite simply make it equally hard for an
experienced hacker to use PHP.

We've been wrangling over this for months, and we *still* don't have
concensus, really -- Even among the people who agree that, in theory, a
consistent naming scheme (with exceptions) is Good, there isn't concensus on
individual cases in reality.

I don't think there's been a single proposed name change that hasn't been
hotly contested.

Maybe it's time to give this up, and move on to other things.



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] 4.0.4pl1 RC2 rolled

[Richard Lynch]

> environment, and win32 mod_php4 happens to be rock solid (when

Is PHP ISAPI rock-solid now?...

That's not the general impression I've received:  If it depends on which
other modules/technoligies you use, that needs to be documented pretty
heavily before one could really call it rock-solid.  And that's the way I
understand it to be at this time.

While I think PHP ISAPI is important, perhaps even critical, I don't want a
billion Windows users to download it because we said it was solid and find
out differently for the technology they need to use it with.  They'll never
come back.



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]