The mere thought of PHP6 scares the living bejesus out of me. I haven’t yet upgraded to PHP5 because of a slower then desired adoption rate and because I have to support legacy applications for some clients. That will all change when PHP 5.1 is released in the near future. I plan on upgrading shortly after it’s released. So for the past year and a half I’ve been thinking about how to implement PHP5 then all of a sudden at this years PHP|Works conference in Toronto, Rasmus Lerdorf shows us a PHP function written in Chinese and said PHP6 is being planned and it will completely support Unicode.
That shook me up a bit, I can’t imagine the day when I open an open source PHP script and find that I can’t read the code in it. Well, I guess some current coding is so bad I can’t read it in plain English anyways, but that’s another story. Here are some excerpts from a recent article discussing a recent meeting in Paris between core developers (Zeev, Dmitri, Andrei, Jani, Wez, Marcus, Rasmus and Derick Rethans)…
I feel it necessary to comment slightly on a few things:
Issue: Register globals are the source of many application’s security problems and cause a constant grief.
1. We are going to remove the functionality.
2. We throw an E_CORE_ERROR when starting PHP and when we detect the register_globals setting
Good, I’m glad to hear register_globals is being removed. I find this annoying having to enable it on a per-client basis right now because people don’t have updated applications. This isn’t a new change PHP 4.1 is old school. This gives me the perfect excuse to say “No” in the future.
Issue: Magic_quotes can be cumbersome for application developers as it is a setting that can be set to on or off without any influence from within the script itself as input parameters are escaped before the script starts.
1. We remove the magic_quotes feature from PHP.
2. We throw an E_CORE_ERROR when starting PHP and when we detect the magic_quotes, magic_quotes_sybase or magic_quotes_gpc setting.
Woah, okay, fair enough. I know magic_quotes are a giant pain the ass, I just never expected they’d be removed. I don’t know why, I guess I never thought about it. All-in-all I think this is good news as it will eventually mean (and I mean eventually as in 5 years from now) I won’t have to detect whether or not magic_quotes are enabled to decide whether to strip slashes or not. One less function.
Issue: safe_mode is a feature in PHP that checks whether files to be opened or included have the same GID/UID as the starting script. This can cause many problems, for example if an application generates a cache file, it will do this with the user ID that belongs to the web server (usually “nobody”). As an application is usually uploaded by the user belonging to the web account (say “client”) the scripts can no longer open the files that the application. The same problems happen when for example an application generates an image.
1. We remove the safe_mode feature from PHP.
2. We throw an E_CORE_ERROR when starting PHP and when we detect the safe_mode setting.
Woah, really? Isn’t this a bit rash? I don’t think that removing safe_mode is a necessary thing to do. I mean, yes there are ways around it, but it does stop HaX3r script kiddie jr. from play where they don’t belong in most cases. Okay, I guess open_basedir does the same. I dunno, that was my initial reaction anyways.
3.8 Allow files with an open stream to be deleted
Issue: Currently it is not possible to delete opened files, and this feature is requested.
1. Wez is going to check for a way on how to make this possible on Windows.
Oh good, I hope they figure this out. I’m plagued by this every now and again on Windows servers.
Oh that’s enough, this is much too long of a discussion. I’m out.