Fellas, >can't see how this should be an issue. It is a security issue. Most ISP's don't allow register_globals to be turned on. Read the php docs about register_globals. Zeev and company explain it better than I can. http://www.php.net/register_globals
It leads to cookie poisoning, header forging, XSS, extremely tough debugging sessions, and all sorts of other nastiness. To quote my (un)orthodox buddy "Never mix da meat with da milk!" They have warned against using this feature for several years, long (WAY long) before they turned it off by default. When I read the manual in the year 2001, I fixed my code, stopped using it and turned it off on all of my servers immediately. I strongly advise against using applications which rely on insecure features. If you really want to solve the register_globals issue, pressure Francisco Burzi (phpNuke) and other open source project leaders to start writing better code and stop relying on insecure features that ISPs don't support. This is the real source of the problem. It is not difficult for them to fix their code. It should have been done a long time ago. The collective aggravation these people cause newbies and ISP's is absolutely staggering. If I had my druthers, RG would be removed from PHP altogether. It is a dangerous relic of times gone by, before such issues were known. I believe in tough love: ) > as a programmer, i hate it how some hosts refuse to keep on top of the > upgrades... They usually don't have time and only patch for major upgrades and major security problems. If you know anyone at an ISP they will tell you what a monumental task it is just to keep all of the servers secure, keeping them on the bleeding edge usually isn't an option, and is way dangerous. You have to consider that by upgrading all the time, in addition to it being nearly impossible, they are risking breaking other customer's applications every single time they upgrade anything. If the upgrade is new, any issues introduced may take weeks to iron out. If your client is down for weeks, at an ISP, they are gone. If it isn't necessary, and the libraries are secure, ISP's usually won't upgrade them. > it's almost a case of "don't upgrade your LAN until the production > server upgrades", but I prefer "convince you host to upgrade, or move > host" :) This is good policy, however, you should have 2 development environments, bleeding edge, where you build new stuff and keep your knowledge up with features, and a copy of production. This way you can code for the latest, find the broken stuff and re-implement for the old version. Usually, depending on just how old production is, there isn't too much that breaks. If you are writing and using classes, as much as possible I hope, when production can take advantage of your latest code, in a year or so, you can simply update the objects. Just keep a consistent interface and you will be fine. > > are now handled by default, the perception being that newer versions > > of PHP > > are incompatible with older code. This perception can be a reality. Curl is a prime example of this. Build a bleeding edge box and try to get curl to work with open ssl. The upgrade to 4.3.2 and the latest openssl broke this. I know, I was bit by it. I had to re-write the curl stuff in Perl::LWP after hammering on curl for a week. The openssl issue was a security one. I will be using Perl for this stuff until OpenSSL/Curl/PHP get on the same page. I sure am glad I know perl: ) If you really want to stay bleeding edge, you should consider co-location. This is where you put your own box in the ISP and maintain and secure it yourself. Then, however, you are on your own with security, not a good place to be. If you neglect it, you get r00ted. I run my own boxes(I am a programmer, not an admin). I only have 8, and it is nearly impossible for me to keep up with only 8 sometimes! I spend a buttload of time on security lists, more than I program. I can't imagine running an ISP with 500+ boxes. Every time I patch a box I run a full scan on it, and check stuff for buffer overflows and regression test my applications. This alone is sometimes 2 days work, sometimes it takes a week if an issue is introduced. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=77467. This security upgrade broke mysql and would have caused our apps to go down, had I not caught it. If we were at an ISP who stayed bleeding edge and blindly upgraded, we would have been shut down by that upgrade for several days. Undoubtedly, we would have fired our ISP (this is one reason we control our boxes, we lose hundreds of thousands of dollars in revenue for every day we are down). This was a critical security upgrade. As soon as I found out about it I upgraded DEV and started testing. If we just went bleeding edge all the time, for the sake of being bleeding edge, nothing would ever work right. Hope this gives you some realistic perspective on why your ISP seems stubborn about upgrading and changing settings. Cut them some slack! It is for your own good (and the good of others). Though painful, it is an unfortunate fact of life. Switching ISP's generally will get you the latest version, for the moment... That honeymoon doesn't last very long. The first time you pressure them into an upgrade that breaks 20 other customers, they will be wiser and you won't get much help from them anymore. Most likely, your current ISP has been here. thx, Neil "behaviour is caused, and the causes are many" ----- Original Message ----- From: "Justin French" <[EMAIL PROTECTED]> To: "Dan Phiffer" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, August 07, 2003 9:43 PM Subject: Re: [PHP] Old version of PHP > On Friday, August 8, 2003, at 09:21 AM, Dan Phiffer wrote: > > > I'm working on an ongoing project that depends on a shared webserver > > running > > an old version of PHP (4.1.2 I believe). Is there any good reason to > > stick > > with an older version of PHP, or might it be a valid suggestion to > > have it > > upgraded to something a bit more recent? I have a notion that upgrade > > attempts may have been snubbed out by the way things like > > register_globals > > are now handled by default, the perception being that newer versions > > of PHP > > are incompatible with older code. > > the register globals "event" happened on 4.1 (from memory), so any > install over that should be straight forward. in any case, it's just > one simple directive that needs to be changed in the php.ini file... > can't see how this should be an issue. > > i think the best reason to keep up-to-date on the versions is that each > new release is "better, more stable, etc etc"... i haven't ever heard > anyone on this list say "i prefer 4.2.3 over 4.2.4" :) > > as a programmer, i hate it how some hosts refuse to keep on top of the > upgrades... really useful functions in newer versions aren't available. > > > > Mainly I'm concerned that code I test on our in-house server running > > version-current PHP will depend on function calls and language > > constructs > > that the production server's vintage PHP interpreter lacks. > > exactly... there isn't a HUGE number of differences between the current > release and what they've got on the live server, but there are > exceptions... i was making good use of file_get_contents() on my LAN, > but had to write a user-function to replicate it when running on the > live server which is stuck at 4.2.3 for the moment. > > it's almost a case of "don't upgrade your LAN until the production > server upgrades", but I prefer "convince you host to upgrade, or move > host" :) > > > Justin > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
