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:
2.1 register_globals
Issue: Register globals are the source of many application’s security problems and cause a constant grief.
Conclusions:
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.
2.2 magic_quotes
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.
Conclusions:
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.
2.3 safe_mode
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.
Conclusions:
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.
Conclusions:
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.
Best Regards,
Matt Simpson
It’s definately time register_globals to go. In fact, it would be nice to see it gone in 5.1 but I doubt that will happen.
magic_quotes is also a bit surprising, but it’s understandable. The issue is not so much removing it or leaving it in, but forcing everyone to have the same behaviour so applications don’t have to check. Taking it out makes as much sense as anything, since data should be stored (in memory) in its original form, and if it needs to be modified to be displayed, permenantly stored, etc, it should be modified on-the-fly to the correct format. This is along the same lines as handling dates as unix timestamps, and converting with date() when displaying, or using nl2br() to show breaks in text a user entered. Most sites should probably turn off magic_quotes if they have it on. A good time to do this would probably be along with a major upgrade, like 4 -> 5.1….
I had the same reaction when I found out about the safe_mode thing, but it does really make sense. As long as open_basedir is still in, things should be okay. You can still lock things down inside their basedir with regular unix permissions, if necessary.
All in all, it’s good they’re talking about PHP6 now, but it’s still a ways off from adoption. It is nice to know what’s being planned though, as it does affect current servers.
I agree, nice (albeit scary) to think about PHP6 and I’m glad they are thinking about. It looks like they’ve be changing a lot of things, mostly for the good. I trust those core developers though, they’re smart guys and they know the best direction to take that’s for sure.
As for turning magic_quotes_gpc off… I’m assuming that when you say that, you’re referring to our server and turning it off when we upgrade. I think that might be a bit too soon. We need to give people some warning so they can make sure their applications are compliant and ready to go.
After we upgrade to PHP 5.1 I will let people know that we are planning on turning off magic_quotes_gpc in 6 months. They’ll have that time to make the switch, if they don’t… well, their applications won’t work. That’s what I did with register_globals. You’ll always have the people complaining after you make the switch because they didn’t do it… but thems the breaks.