Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Michael A. Peters wrote: Robert Cummings wrote: Michael A. Peters wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. While the majority of the students use Windows, I'm aware that a vast amount will be using Ubuntu/Debian (and some use Gentoo, Fedora and Arch) distributions of Linux, so I'm hoping there won't be too many problems on installation. I don't want to waste the entire first class fixing installation problems, because that kills the student's motivation. The course starts on August, but I'm preparing it during the last two weeks of July. You think that installation packages will be bulletproof by then? Or should I just teach 5.2 and wait for another semester before starting on 5.3? I mean, most hosts will remain with PHP 5.2 for the rest of the year, so I'm a bit confused on what I should do. I'm just a university student that wants to spread PHP, for I've been using it for many years now =) Thanks for the advices, Mamsaac Many hosts are still on php 5.1.x (IE RHEL based hosts). I would be worried that many popular classes and apps might be quirky under 5.3. I've not played with it at all, and probably won't for some time, but I've been bitten by that more than once. Nice thing about 5.2.x as far as linux goes anyway, installing it is cake from the package repositories. Using package repositories for php installs is suggested as security fixes can be updated with ease. As someone running a newer version of php (5.2.9) than what my distro ships with, here are some of the issues: A) I needed to create packages so that I could RPM install various stuff, like Squirelmail, etc. - and get the security updates for them from my OS vendor (CentOS or EPEL repods). So to do that, I used the Fedora src.rpm. B) When building php rpm's on my system, the %check portion of the spec file (runs make test I believe) fails sometimes if there is an existing php install. To solve that, you have to build it in mock. C) Mock needs a lot of disk space and will download a lot of packages, if you don't local mirror the update repositories, it can be really time consuming. Furthermore, occasionally the build list for mock is broken making it un-usable for package building. I have to use 5.2.x because I need a pecl extension that does not work with 5.1.x - and building rpm myself lets me add suhosin patch (to the fedora spec file) but unless your Linux students want to do absolutely everything php by source and not have anything installed from the package managers that rely on php, I would highly suggest that they use whatever version of php their distro of choice has in its stable repositories. -=- Since you are teaching students, one pet peeve of mine that I see in web app after web app after web app - they have an admin interface that writes a php file which the app then parses as php. Often they even instruct the person installing the web app to have 777 permissions of directories and/or files within the web root. There's a better way. Either store the configuration settings in a database (obviously can't store database connection setting in the database ...) or store them in an xml file, not php. You can write and read the xml file with any number of existing php functions. And the config file should not be in the web root, nothing the web server can write to should be in the document root. Applications (like Gallery and I think joomla and wordpress) often want write permission to the document root so they can have a web interface to install/update their modules - but it creates a security risk. It's better to install the modules you want from a distro vendor repository so you can keep them up to date that way, and hence, it's better to use a packaged php install so that the dependencies are met. Sorry for rambling, but the trend of web server having write permissions to files the web server then executes (and often in the web root) is a trend that needs to stop. So flunk the students that do it ;) And how do you propose people get around open_basedir restrictions which is common in many Plesk environments? There is nothing wrong with having the above mentioned write access if it is properly protected. Nothing wrong other than any vulnerability in apache (or a module apache loads or cgi/server script code) that allows a malicious user to write data as the apache user can now do so inside the web root where they can then request it causing php/perl/python/whatever to execute the code they just wrote. This is fear mongering. I could make the same argument that making use of a webserver opens you up to any vulnerability in the webserver that may provide access to the entire filesystem. The
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Robert Cummings wrote: Michael A. Peters wrote: Robert Cummings wrote: Michael A. Peters wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. While the majority of the students use Windows, I'm aware that a vast amount will be using Ubuntu/Debian (and some use Gentoo, Fedora and Arch) distributions of Linux, so I'm hoping there won't be too many problems on installation. I don't want to waste the entire first class fixing installation problems, because that kills the student's motivation. The course starts on August, but I'm preparing it during the last two weeks of July. You think that installation packages will be bulletproof by then? Or should I just teach 5.2 and wait for another semester before starting on 5.3? I mean, most hosts will remain with PHP 5.2 for the rest of the year, so I'm a bit confused on what I should do. I'm just a university student that wants to spread PHP, for I've been using it for many years now =) Thanks for the advices, Mamsaac Many hosts are still on php 5.1.x (IE RHEL based hosts). I would be worried that many popular classes and apps might be quirky under 5.3. I've not played with it at all, and probably won't for some time, but I've been bitten by that more than once. Nice thing about 5.2.x as far as linux goes anyway, installing it is cake from the package repositories. Using package repositories for php installs is suggested as security fixes can be updated with ease. As someone running a newer version of php (5.2.9) than what my distro ships with, here are some of the issues: A) I needed to create packages so that I could RPM install various stuff, like Squirelmail, etc. - and get the security updates for them from my OS vendor (CentOS or EPEL repods). So to do that, I used the Fedora src.rpm. B) When building php rpm's on my system, the %check portion of the spec file (runs make test I believe) fails sometimes if there is an existing php install. To solve that, you have to build it in mock. C) Mock needs a lot of disk space and will download a lot of packages, if you don't local mirror the update repositories, it can be really time consuming. Furthermore, occasionally the build list for mock is broken making it un-usable for package building. I have to use 5.2.x because I need a pecl extension that does not work with 5.1.x - and building rpm myself lets me add suhosin patch (to the fedora spec file) but unless your Linux students want to do absolutely everything php by source and not have anything installed from the package managers that rely on php, I would highly suggest that they use whatever version of php their distro of choice has in its stable repositories. -=- Since you are teaching students, one pet peeve of mine that I see in web app after web app after web app - they have an admin interface that writes a php file which the app then parses as php. Often they even instruct the person installing the web app to have 777 permissions of directories and/or files within the web root. There's a better way. Either store the configuration settings in a database (obviously can't store database connection setting in the database ...) or store them in an xml file, not php. You can write and read the xml file with any number of existing php functions. And the config file should not be in the web root, nothing the web server can write to should be in the document root. Applications (like Gallery and I think joomla and wordpress) often want write permission to the document root so they can have a web interface to install/update their modules - but it creates a security risk. It's better to install the modules you want from a distro vendor repository so you can keep them up to date that way, and hence, it's better to use a packaged php install so that the dependencies are met. Sorry for rambling, but the trend of web server having write permissions to files the web server then executes (and often in the web root) is a trend that needs to stop. So flunk the students that do it ;) And how do you propose people get around open_basedir restrictions which is common in many Plesk environments? There is nothing wrong with having the above mentioned write access if it is properly protected. Nothing wrong other than any vulnerability in apache (or a module apache loads or cgi/server script code) that allows a malicious user to write data as the apache user can now do so inside the web root where they can then request it causing php/perl/python/whatever to execute the code they just wrote. This is fear mongering. No. It is not. The web root should be read only. I could make the same argument that making use of a webserver opens you up to any vulnerability
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Michael A. Peters wrote: Robert Cummings wrote: Michael A. Peters wrote: Robert Cummings wrote: Michael A. Peters wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. While the majority of the students use Windows, I'm aware that a vast amount will be using Ubuntu/Debian (and some use Gentoo, Fedora and Arch) distributions of Linux, so I'm hoping there won't be too many problems on installation. I don't want to waste the entire first class fixing installation problems, because that kills the student's motivation. The course starts on August, but I'm preparing it during the last two weeks of July. You think that installation packages will be bulletproof by then? Or should I just teach 5.2 and wait for another semester before starting on 5.3? I mean, most hosts will remain with PHP 5.2 for the rest of the year, so I'm a bit confused on what I should do. I'm just a university student that wants to spread PHP, for I've been using it for many years now =) Thanks for the advices, Mamsaac Many hosts are still on php 5.1.x (IE RHEL based hosts). I would be worried that many popular classes and apps might be quirky under 5.3. I've not played with it at all, and probably won't for some time, but I've been bitten by that more than once. Nice thing about 5.2.x as far as linux goes anyway, installing it is cake from the package repositories. Using package repositories for php installs is suggested as security fixes can be updated with ease. As someone running a newer version of php (5.2.9) than what my distro ships with, here are some of the issues: A) I needed to create packages so that I could RPM install various stuff, like Squirelmail, etc. - and get the security updates for them from my OS vendor (CentOS or EPEL repods). So to do that, I used the Fedora src.rpm. B) When building php rpm's on my system, the %check portion of the spec file (runs make test I believe) fails sometimes if there is an existing php install. To solve that, you have to build it in mock. C) Mock needs a lot of disk space and will download a lot of packages, if you don't local mirror the update repositories, it can be really time consuming. Furthermore, occasionally the build list for mock is broken making it un-usable for package building. I have to use 5.2.x because I need a pecl extension that does not work with 5.1.x - and building rpm myself lets me add suhosin patch (to the fedora spec file) but unless your Linux students want to do absolutely everything php by source and not have anything installed from the package managers that rely on php, I would highly suggest that they use whatever version of php their distro of choice has in its stable repositories. -=- Since you are teaching students, one pet peeve of mine that I see in web app after web app after web app - they have an admin interface that writes a php file which the app then parses as php. Often they even instruct the person installing the web app to have 777 permissions of directories and/or files within the web root. There's a better way. Either store the configuration settings in a database (obviously can't store database connection setting in the database ...) or store them in an xml file, not php. You can write and read the xml file with any number of existing php functions. And the config file should not be in the web root, nothing the web server can write to should be in the document root. Applications (like Gallery and I think joomla and wordpress) often want write permission to the document root so they can have a web interface to install/update their modules - but it creates a security risk. It's better to install the modules you want from a distro vendor repository so you can keep them up to date that way, and hence, it's better to use a packaged php install so that the dependencies are met. Sorry for rambling, but the trend of web server having write permissions to files the web server then executes (and often in the web root) is a trend that needs to stop. So flunk the students that do it ;) And how do you propose people get around open_basedir restrictions which is common in many Plesk environments? There is nothing wrong with having the above mentioned write access if it is properly protected. Nothing wrong other than any vulnerability in apache (or a module apache loads or cgi/server script code) that allows a malicious user to write data as the apache user can now do so inside the web root where they can then request it causing php/perl/python/whatever to execute the code they just wrote. This is fear mongering. No. It is not. The web root should be read only. Please cite references as to why it should be read only. Please explain
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Robert Cummings wrote: It's hard to create a helpful application when fort knox is your delivery location. I'm not saying there's a problem with Fort Knoxes in the world, but this isn't necessary for everyone. if it were we wouldn't have banks, we wouldn't have credit unions, we'd all be going to Fort Knox to make our deposits and withdrawals. One size does NOT fit all. If you're running with AppArmor or SELinux in 'enforce' mode, we could begin to talk about Fort Knox, but not letting the webserver write to the DocumentRoot is just a pretty sound precaution. It is unfortunate that many popular PHP apps were written/designed to expect that kind of access (at least during initial configuration). modules), so one should have a strict policy of never having directories or files inside the web root that the web server has write permission to. Why? You still haven't given a good reason. I am the master of my environment, if I know what I'm putting into my environment then who is to tell me my setup is wrong? Rob, for the same reason you make all kinds of other restrictions - you are not necessarily the master of your own environment. I also think I am the master of my mailserver, but I still run a firewall. /Per -- Per Jessen, Zürich (11.5°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Per Jessen wrote: Robert Cummings wrote: It's hard to create a helpful application when fort knox is your delivery location. I'm not saying there's a problem with Fort Knoxes in the world, but this isn't necessary for everyone. if it were we wouldn't have banks, we wouldn't have credit unions, we'd all be going to Fort Knox to make our deposits and withdrawals. One size does NOT fit all. If you're running with AppArmor or SELinux in 'enforce' mode, we could begin to talk about Fort Knox, but not letting the webserver write to the DocumentRoot is just a pretty sound precaution. It is unfortunate that many popular PHP apps were written/designed to expect that kind of access (at least during initial configuration). modules), so one should have a strict policy of never having directories or files inside the web root that the web server has write permission to. Why? You still haven't given a good reason. I am the master of my environment, if I know what I'm putting into my environment then who is to tell me my setup is wrong? Rob, for the same reason you make all kinds of other restrictions - you are not necessarily the master of your own environment. I also think I am the master of my mailserver, but I still run a firewall. You run a firewall BECAUSE you are the master of your environment. Similarly, I choose a host that has or has not restrictions BECAUSE I am the master of my environment. Mastery includes what you choose for yourself. Personally, I prefer having my code outside the DocumentRoot also, but I do not believe it is the simplest solution, and I do not think it is wrong to place such information within the DocumentRoot. The feature exists, application developers have chosen to use the feature, it may be less secure, but it is not wrong. Not using AppArmor is less secure, but it is not wrong. It is one thing for Michael to argue that it is less secure, but he did not, he claimed the DocumentRoot should be read only and otherwise is wrong. This fundamentally changes the nature of the debate. Your argument is perfectly valid less secure, perhaps, but wrong? Should never be done? Sorry, I'm not swallowing the medicine. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Per Jessen wrote: Robert Cummings wrote: Personally, I prefer having my code outside the DocumentRoot also, but I do not believe it is the simplest solution, and I do not think it is wrong to place such information within the DocumentRoot. The feature exists, application developers have chosen to use the feature, it may be less secure, but it is not wrong. Are we just discussing semantics then? I agree it's not wrong as such, but right and wrong are usually determined by the environment one is in and in a security-aware environment (such as I know them), letting the webserver write to the DocumentRoot would be wrong. Elsewhere it is perhaps at worst ill-advised. I prefer proceed with caution :) Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
On Wed, Jun 24, 2009 at 13:24, Robert Cummingsrob...@interjinn.com wrote: I prefer proceed with caution :) Robjects in mirror are closer than they appear? -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ 50% Off All Shared Hosting Plans at PilotPig: Use Coupon DOW1 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
-Original Message- From: paras...@gmail.com [mailto:paras...@gmail.com] On Behalf Of Daniel Brown Sent: Wednesday, June 24, 2009 1:34 PM To: Robert Cummings Cc: Per Jessen; php-general@lists.php.net Subject: Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course) On Wed, Jun 24, 2009 at 13:24, Robert Cummingsrob...@interjinn.com wrote: I prefer proceed with caution :) Robjects in mirror are closer than they appear? -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ 50% Off All Shared Hosting Plans at PilotPig: Use Coupon DOW1 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php __ Information from ESET Smart Security, version of virus signature database 4185 (20090624) __ The message was checked by ESET Smart Security. http://www.eset.com [Marc Hall - HallMarc Websites - http://www.hallmarcwebsites.com 610.446.3346] Nice one. :o) Now, for my two centavos: I think anyone needs to base any decision regarding security measures within the context of the current project and what it is you are trying to protect. It seems to go without saying that you should also be aware of your host environment and any limitations, etc that may arise. Fort Knox has the security that it does because of what it is contracted to protect while the banks have their own pared down version of security based on what they are protecting. As far as which version of PHP to include in your curriculum, I suggest staying with 5.2 for now and add in information about 5.3 and the changes we expect to see and what they mean to all concerned. As I once saw in someone elses sig line Invoice for $0.02 will be sent post-haste. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Robert Cummings wrote: * snip * No. It is not. The web root should be read only. Please cite references as to why it should be read only. Please explain why the feature exists if it should not be so. The feature exists because the web server runs as a standard user, and standard users have permission to directories they have write permission to. In a properly administered web server, the apache user only has read permission to the contents of the web root. I could make the same argument that making use of a webserver opens you up to any vulnerability in the webserver that may provide access to the entire filesystem. The intended purpose of the webserver is not to allow such access when configured properly, and so it is an exceptional circumstance when such security is compromised. These compromises do happen, which is why the web root should be read only to the web server and any data the web server has write access to should be validated before it is used. And the operating system? Operating system doesn't matter. The web server should not have write permission to directories/files within the web root. It isn't hard to do. It's hard to create a helpful application when fort knox is your delivery location. I'm not saying there's a problem with Fort Knoxes in the world, but this isn't necessary for everyone. if it were we wouldn't have banks, we wouldn't have credit unions, we'd all be going to Fort Knox to make our deposits and withdrawals. One size does NOT fit all. I'm sick and tired of owned boxes spamming me. It's been so bad at time I though my spam filters were crap, and I looked at the large number of messages they did catch. I'm tired of XSS attacks. I run with scripting disabled for most sites, which makes the web a pain in the arse because most web pages out there are done by clueless hacks who expect me to allow them to send arbitrary code to be executed on my machine. Very often these XSS attacks are the result of compromised boxes. Yes, people need to run secure web servers. Yes, application developers need to take security into consideration before uploading their project for public consumption. Kind of scenario that happens all the time: Jane, a non technical person, has a soft spot for the Desert Tortoise. She buys a cheap web account and sets up a blog on it. She gives an account to her friend betty. Betty's webmail account is compromised by an XSS attack (happens all the time, even has happened to gmail). Now the attacker has access to Betty's mail including her password. He logs on to Betty's account and modifies a blog, adding an image that isn't an image, and either successfully now has an XSS attack on Jane's blog, or possibly have even rooted the server Jane's account is with through a local exploit he was able to get the apache server to run because he was able to upload a perl or php script inside the web root. Just as an example, I was looking for a simplistic blog to add to my website. The install script didn't even work because it used system and exec calls which many servers (including mine) do not allow. This is a problem with your setup. I make use of exec() calls often enough when within a Linux environment. If this is a known parameter of the application, then it is not incorrect to use exec(). It is common to build upon existing shell binaries. Vast majority of stuff can be done with pure php via php modules and extensions. Allowing exec() or system() is extremely dangerous. Yes, I do allow it for my squirrelmail install, but fixing that is on my todo list. A specific instance of a poorly designed application does not stand as the model for all applications. There are countless examples of bad programming and exploits at pretty much every level of a system. These do not suggest we should not use computers. No, but it does suggest we need to think about security, such as not having web server writeable files in the web root and not having the web server write files it then parses as php (extremely common practice for app configuration files) - especially when it is cake to use a database or flat file (IE xml) for configuration, allowing parsing of the values read to make sure they are sane and avoiding addition of declarations you don't want. So with some hand waving and fluttering of your eyes you've eliminated (or at least completely ignored) all the Windows machines in the world. No. I haven't. For years, the LaTeX community had a package manager for Windows installs that was in fact superior to any TeX package management on any UN*X environment I ever saw. Now with TeXLive tlmgr there is finally good TeX package management for every OS. There are far more php users than TeX users, there is no good reason why such a package manager does not already exist for php in the Windows environment. It would be an excellent addition to the WAMP stack. The Windows
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
On Wed, Jun 24, 2009 at 17:19, Michael A. Petersmpet...@mac.com wrote: Jane, a non technical person [...] Betty's webmail account is compromised [...] Bottom line: hax0r5 hate g1rls. -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ 50% Off All Shared Hosting Plans at PilotPig: Use Coupon DOW1 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Michael A. Peters wrote: Robert Cummings wrote: * snip * No. It is not. The web root should be read only. Please cite references as to why it should be read only. Please explain why the feature exists if it should not be so. The feature exists because the web server runs as a standard user, and standard users have permission to directories they have write permission to. In a properly administered web server, the apache user only has read permission to the contents of the web root. I could make the same argument that making use of a webserver opens you up to any vulnerability in the webserver that may provide access to the entire filesystem. The intended purpose of the webserver is not to allow such access when configured properly, and so it is an exceptional circumstance when such security is compromised. These compromises do happen, which is why the web root should be read only to the web server and any data the web server has write access to should be validated before it is used. And the operating system? Operating system doesn't matter. The web server should not have write permission to directories/files within the web root. It isn't hard to do. It's hard to create a helpful application when fort knox is your delivery location. I'm not saying there's a problem with Fort Knoxes in the world, but this isn't necessary for everyone. if it were we wouldn't have banks, we wouldn't have credit unions, we'd all be going to Fort Knox to make our deposits and withdrawals. One size does NOT fit all. I'm sick and tired of owned boxes spamming me. It's been so bad at time I though my spam filters were crap, and I looked at the large number of messages they did catch. I'm tired of XSS attacks. I run with scripting disabled for most sites, which makes the web a pain in the arse because most web pages out there are done by clueless hacks who expect me to allow them to send arbitrary code to be executed on my machine. Very often these XSS attacks are the result of compromised boxes. Yes, people need to run secure web servers. Yes, application developers need to take security into consideration before uploading their project for public consumption. Kind of scenario that happens all the time: Jane, a non technical person, has a soft spot for the Desert Tortoise. She buys a cheap web account and sets up a blog on it. She gives an account to her friend betty. Betty's webmail account is compromised by an XSS attack (happens all the time, even has happened to gmail). Now the attacker has access to Betty's mail including her password. He logs on to Betty's account and modifies a blog, adding an image that isn't an image, and either successfully now has an XSS attack on Jane's blog, or possibly have even rooted the server Jane's account is with through a local exploit he was able to get the apache server to run because he was able to upload a perl or php script inside the web root. Just as an example, I was looking for a simplistic blog to add to my website. The install script didn't even work because it used system and exec calls which many servers (including mine) do not allow. This is a problem with your setup. I make use of exec() calls often enough when within a Linux environment. If this is a known parameter of the application, then it is not incorrect to use exec(). It is common to build upon existing shell binaries. Vast majority of stuff can be done with pure php via php modules and extensions. Allowing exec() or system() is extremely dangerous. Yes, I do allow it for my squirrelmail install, but fixing that is on my todo list. A specific instance of a poorly designed application does not stand as the model for all applications. There are countless examples of bad programming and exploits at pretty much every level of a system. These do not suggest we should not use computers. No, but it does suggest we need to think about security, such as not having web server writeable files in the web root and not having the web server write files it then parses as php (extremely common practice for app configuration files) - especially when it is cake to use a database or flat file (IE xml) for configuration, allowing parsing of the values read to make sure they are sane and avoiding addition of declarations you don't want. So with some hand waving and fluttering of your eyes you've eliminated (or at least completely ignored) all the Windows machines in the world. No. I haven't. For years, the LaTeX community had a package manager for Windows installs that was in fact superior to any TeX package management on any UN*X environment I ever saw. Now with TeXLive tlmgr there is finally good TeX package management for every OS. There are far more php users than TeX users, there is no good reason why such a package manager does not already exist for php in the Windows environment. It would be an excellent addition to the WAMP stack. The
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Robert Cummings wrote: I respectfully disagree with your position. Everything you have described about Jane is also true of an operating system. There are compromised machines all over the world just because installing an operating system is so easy. No amount of packaging is going to solve the problem created by bad software and idiots. But php coders writing code that follows basic policy rules does reduce the problem. Such policies include not writing your app so the install instructions tell the user to chmod 777 directories and files within the web root. Since the OP is teaching a class, that's an important concept student need to understand. Yes, there will always be mis-behaving apps. There will also be well written applications that are vulnerable simply because they use a vulnerable module or class. Creating a secure development policy and implementing it greatly reduces your well written application from being an attack vector when those issues exist, and they will always exist. Similarly, web developers (php and other) need to start following and implementing the CSP recommendation at Mozilla.org. In a perfect world where we could guarantee our web apps were not vulnerable to XSS injection, a web app would never have to send headers telling the client what is allowed and from where, but as we don't live in a perfect world, it is the right thing to do - even though it makes coding a lot more tedious. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
On Wed, Jun 24, 2009 at 05:26:11PM -0400, Daniel Brown wrote: On Wed, Jun 24, 2009 at 17:19, Michael A. Petersmpet...@mac.com wrote: Jane, a non technical person [...] Betty's webmail account is compromised [...] Bottom line: hax0r5 hate g1rls. Or hax0r5 hate grrls. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. Does it _really_ matter which one? I can't imagine there are that many revolutionary changes in a dot-release. /Per -- Per Jessen, Zürich (12.2°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Why not give a presentation, like in the first few, about compiling PHP for yourself, as that's a pretty useful skill that's oft neglected? On Tue, Jun 23, 2009 at 4:12 AM, Per Jessenp...@computer.org wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. Does it _really_ matter which one? I can't imagine there are that many revolutionary changes in a dot-release. /Per -- Per Jessen, Zürich (12.2°C) -- 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
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
The thing is, that part of the planned course was to develop a small framework, so that they could see the dynamic and OOP posibilities that PHP offers. With PHP 5.3, there are namespaces, which change a lot the design of a framework, as well as true lambdas with closures. So, naturally, the architecture of this minimalistic framework changes and I have plans to write it before the course starts. Why a framework? If you know how an MVC framework is created and how it works, you will most likely get into Zend Framework or CakePHP much faster. Plus, it's a very good way to learn the language. It wouldn't be the first one I've written, so it's not much trouble. That's why I care about PHP 5.3. Now imagine if there were Traits! Anyway, I think I will do as someone mentioned, and teach them 5.2 during the entire course and then at the end show them some of 5.3. -- Forwarded message -- From: Per Jessen p...@computer.org To: php-general@lists.php.net Date: Tue, 23 Jun 2009 10:12:55 +0200 Subject: Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course) Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. Does it _really_ matter which one? I can't imagine there are that many revolutionary changes in a dot-release.
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Per Jessen wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. Does it _really_ matter which one? I can't imagine there are that many revolutionary changes in a dot-release. Given the naming of PHP versions of PHP-x.y.z, I would agree that not much changes between versions at the .z level. But at the .y level there are usually significant changes. Coming to a PHP 5.3 near you are the following notable features: - namespaces - closures - late static binding - garbage collector to handle cyclic references - PHAR - goto Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Manuel Aude wrote: The thing is, that part of the planned course was to develop a small framework, so that they could see the dynamic and OOP posibilities that PHP offers. With PHP 5.3, there are namespaces, which change a lot the design of a framework, as well as true lambdas with closures. So, naturally, the architecture of this minimalistic framework changes and I have plans to write it before the course starts. Why a framework? If you know how an MVC framework is created and how it works, you will most likely get into Zend Framework or CakePHP much faster. Plus, it's a very good way to learn the language. It wouldn't be the first one I've written, so it's not much trouble. That's why I care about PHP 5.3. Now imagine if there were Traits! Anyway, I think I will do as someone mentioned, and teach them 5.2 during the entire course and then at the end show them some of 5.3. I think going with 5.2 and then showing them the possibilities with 5.3 afterwards is a good approach. This way when they finish they can work within older environments as well as the new. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Robert Cummings wrote: Per Jessen wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. Does it _really_ matter which one? I can't imagine there are that many revolutionary changes in a dot-release. Given the naming of PHP versions of PHP-x.y.z, I would agree that not much changes between versions at the .z level. But at the .y level there are usually significant changes. Coming to a PHP 5.3 near you are the following notable features: - namespaces - closures - late static binding - garbage collector to handle cyclic references - PHAR - goto I hadn't actually seen/studied the list, but apart from the goto, I don't consider any of those revolutionary :-) /Per -- Per Jessen, Zürich (13.8°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Per Jessen wrote: Robert Cummings wrote: Per Jessen wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. Does it _really_ matter which one? I can't imagine there are that many revolutionary changes in a dot-release. Given the naming of PHP versions of PHP-x.y.z, I would agree that not much changes between versions at the .z level. But at the .y level there are usually significant changes. Coming to a PHP 5.3 near you are the following notable features: - namespaces - closures - late static binding - garbage collector to handle cyclic references - PHAR - goto I hadn't actually seen/studied the list, but apart from the goto, I don't consider any of those revolutionary :-) Revolutionary, no. Major changes for PHP, yes! Major shifts in development practices for PHP... it depends on who you are or where you work, but certainly some of these will mark changes in development for many people. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Robert Cummings wrote: Per Jessen wrote: Coming to a PHP 5.3 near you are the following notable features: - namespaces - closures - late static binding - garbage collector to handle cyclic references - PHAR - goto I hadn't actually seen/studied the list, but apart from the goto, I don't consider any of those revolutionary :-) Revolutionary, no. Major changes for PHP, yes! Major shifts in development practices for PHP... it depends on who you are or where you work, but certainly some of these will mark changes in development for many people. Yes, I do see that - it won't mean much to my own PHP development, which is probably clouding my view. /Per -- Per Jessen, Zürich (13.4°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. While the majority of the students use Windows, I'm aware that a vast amount will be using Ubuntu/Debian (and some use Gentoo, Fedora and Arch) distributions of Linux, so I'm hoping there won't be too many problems on installation. I don't want to waste the entire first class fixing installation problems, because that kills the student's motivation. The course starts on August, but I'm preparing it during the last two weeks of July. You think that installation packages will be bulletproof by then? Or should I just teach 5.2 and wait for another semester before starting on 5.3? I mean, most hosts will remain with PHP 5.2 for the rest of the year, so I'm a bit confused on what I should do. I'm just a university student that wants to spread PHP, for I've been using it for many years now =) Thanks for the advices, Mamsaac Many hosts are still on php 5.1.x (IE RHEL based hosts). I would be worried that many popular classes and apps might be quirky under 5.3. I've not played with it at all, and probably won't for some time, but I've been bitten by that more than once. Nice thing about 5.2.x as far as linux goes anyway, installing it is cake from the package repositories. Using package repositories for php installs is suggested as security fixes can be updated with ease. As someone running a newer version of php (5.2.9) than what my distro ships with, here are some of the issues: A) I needed to create packages so that I could RPM install various stuff, like Squirelmail, etc. - and get the security updates for them from my OS vendor (CentOS or EPEL repods). So to do that, I used the Fedora src.rpm. B) When building php rpm's on my system, the %check portion of the spec file (runs make test I believe) fails sometimes if there is an existing php install. To solve that, you have to build it in mock. C) Mock needs a lot of disk space and will download a lot of packages, if you don't local mirror the update repositories, it can be really time consuming. Furthermore, occasionally the build list for mock is broken making it un-usable for package building. I have to use 5.2.x because I need a pecl extension that does not work with 5.1.x - and building rpm myself lets me add suhosin patch (to the fedora spec file) but unless your Linux students want to do absolutely everything php by source and not have anything installed from the package managers that rely on php, I would highly suggest that they use whatever version of php their distro of choice has in its stable repositories. -=- Since you are teaching students, one pet peeve of mine that I see in web app after web app after web app - they have an admin interface that writes a php file which the app then parses as php. Often they even instruct the person installing the web app to have 777 permissions of directories and/or files within the web root. There's a better way. Either store the configuration settings in a database (obviously can't store database connection setting in the database ...) or store them in an xml file, not php. You can write and read the xml file with any number of existing php functions. And the config file should not be in the web root, nothing the web server can write to should be in the document root. Applications (like Gallery and I think joomla and wordpress) often want write permission to the document root so they can have a web interface to install/update their modules - but it creates a security risk. It's better to install the modules you want from a distro vendor repository so you can keep them up to date that way, and hence, it's better to use a packaged php install so that the dependencies are met. Sorry for rambling, but the trend of web server having write permissions to files the web server then executes (and often in the web root) is a trend that needs to stop. So flunk the students that do it ;) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Michael A. Peters wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. While the majority of the students use Windows, I'm aware that a vast amount will be using Ubuntu/Debian (and some use Gentoo, Fedora and Arch) distributions of Linux, so I'm hoping there won't be too many problems on installation. I don't want to waste the entire first class fixing installation problems, because that kills the student's motivation. The course starts on August, but I'm preparing it during the last two weeks of July. You think that installation packages will be bulletproof by then? Or should I just teach 5.2 and wait for another semester before starting on 5.3? I mean, most hosts will remain with PHP 5.2 for the rest of the year, so I'm a bit confused on what I should do. I'm just a university student that wants to spread PHP, for I've been using it for many years now =) Thanks for the advices, Mamsaac Many hosts are still on php 5.1.x (IE RHEL based hosts). I would be worried that many popular classes and apps might be quirky under 5.3. I've not played with it at all, and probably won't for some time, but I've been bitten by that more than once. Nice thing about 5.2.x as far as linux goes anyway, installing it is cake from the package repositories. Using package repositories for php installs is suggested as security fixes can be updated with ease. As someone running a newer version of php (5.2.9) than what my distro ships with, here are some of the issues: A) I needed to create packages so that I could RPM install various stuff, like Squirelmail, etc. - and get the security updates for them from my OS vendor (CentOS or EPEL repods). So to do that, I used the Fedora src.rpm. B) When building php rpm's on my system, the %check portion of the spec file (runs make test I believe) fails sometimes if there is an existing php install. To solve that, you have to build it in mock. C) Mock needs a lot of disk space and will download a lot of packages, if you don't local mirror the update repositories, it can be really time consuming. Furthermore, occasionally the build list for mock is broken making it un-usable for package building. I have to use 5.2.x because I need a pecl extension that does not work with 5.1.x - and building rpm myself lets me add suhosin patch (to the fedora spec file) but unless your Linux students want to do absolutely everything php by source and not have anything installed from the package managers that rely on php, I would highly suggest that they use whatever version of php their distro of choice has in its stable repositories. -=- Since you are teaching students, one pet peeve of mine that I see in web app after web app after web app - they have an admin interface that writes a php file which the app then parses as php. Often they even instruct the person installing the web app to have 777 permissions of directories and/or files within the web root. There's a better way. Either store the configuration settings in a database (obviously can't store database connection setting in the database ...) or store them in an xml file, not php. You can write and read the xml file with any number of existing php functions. And the config file should not be in the web root, nothing the web server can write to should be in the document root. Applications (like Gallery and I think joomla and wordpress) often want write permission to the document root so they can have a web interface to install/update their modules - but it creates a security risk. It's better to install the modules you want from a distro vendor repository so you can keep them up to date that way, and hence, it's better to use a packaged php install so that the dependencies are met. Sorry for rambling, but the trend of web server having write permissions to files the web server then executes (and often in the web root) is a trend that needs to stop. So flunk the students that do it ;) And how do you propose people get around open_basedir restrictions which is common in many Plesk environments? There is nothing wrong with having the above mentioned write access if it is properly protected. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
On Tue, Jun 23, 2009 at 04:12, Per Jessenp...@computer.org wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. Does it _really_ matter which one? I can't imagine there are that many revolutionary changes in a dot-release. There are some major changes and additions introduced in 5.3. However, some may consider it a wise idea to wait until at least 5.3.1 before putting it into production. The public final release of PHP 5.3.0 is still a few days off, so starting with 5.2 and then introducing the 5.3 branch during the course could not only be a great idea for the OP, but also an exciting evolution during the class, showing also in real-time how open source projects advance. -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ 50% Off All Shared Hosting Plans at PilotPig: Use Coupon DOW1 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
From: Michael A. Peters Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. While the majority of the students use Windows, I'm aware that a vast amount will be using Ubuntu/Debian (and some use Gentoo, Fedora and Arch) distributions of Linux, so I'm hoping there won't be too many problems on installation. I don't want to waste the entire first class fixing installation problems, because that kills the student's motivation. The course starts on August, but I'm preparing it during the last two weeks of July. You think that installation packages will be bulletproof by then? Or should I just teach 5.2 and wait for another semester before starting on 5.3? I mean, most hosts will remain with PHP 5.2 for the rest of the year, so I'm a bit confused on what I should do. I'm just a university student that wants to spread PHP, for I've been using it for many years now =) Many hosts are still on php 5.1.x (IE RHEL based hosts). I would be worried that many popular classes and apps might be quirky under 5.3. I've not played with it at all, and probably won't for some time, but I've been bitten by that more than once. Nice thing about 5.2.x as far as linux goes anyway, installing it is cake from the package repositories. Using package repositories for php installs is suggested as security fixes can be updated with ease. As someone running a newer version of php (5.2.9) than what my distro ships with, here are some of the issues: Manuel, You might want to check on the release schedules for PHP 5.3(.1?) by the major distributions. Even if they are close to the end of your class schedule, will they be deployed that quickly to sites your students could be working on? Or will they still be working with 5.2 for the foreseeable future? I have recently been told that we are switching from compiling Apache, PHP and PostgreSQL ourselves to only using the official RedHat RPMs on our production servers[*]. This is coupled with a move to a managed hosting service. But since RH is not even shipping the most recent version of 5.2, I don't expect to see a 5.3 RPM for some time. Maybe it will have enough improvements to trigger an early update from them, but who knows. After they release it, it will still be a while before we pick it up, test it and deploy it. So even though I like some of the changes in 5.3, I am stuck with 5.2 for at least another year, maybe two. Bob McConnell [*] No, I don't like this at all. I see it as the antithesis of both the Open Source and Free Software philosophies. It means we give up control of some of the options we were selecting at compile time and have to settle for somebody else's idea of the perfect server. I fully expect it will come back to bite us at some point. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
On Tue, Jun 23, 2009 at 2:34 AM, Robert Cummings rob...@interjinn.com wrote: Revolutionary, no. Major changes for PHP, yes! Major shifts in development practices for PHP... it depends on who you are or where you work, but certainly some of these will mark changes in development for many people. +1 http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?revision=PHP_5_3 Depending on your output you may start getting a lot of errors, warnings and deprecation messages. Not to mention, every error thrown is overhead in the system, regardless if it is being displayed or logged. (as Rasmus says, write error free code) Behavior changes that can affect people's code from either the I assume this is defaulted this way, behavior changes or deprecation changes from what I can grok from that - quite a few that people should probably be looking for ahead of time, and writing 5.3 safe versions of their code, and ensuring they have the ini variables defined to what they want that will be changing their defaults too... - **namespace** and **goto** are now reserved keywords. - **Closure** is now a reserved class. (Used by lambda and closure.) - The array functions natsort(), natcasesort(), usort(), uasort(), uksort(), array_flip() and array_unique(), no longer accept objects passed as arguments. If you need to access their properties using an object, you will need to cast the objects to arrays first. - The behaviour of functions with by-reference parameters called by value has changed. Where previously the function would accept the by-value argument, a warning is now emitted and all by-ref parameters are set to NULL. - The magic methods __get(), __set(), __isset(), __unset() and __call() should always be public and can no longer be static. Method signatures are enforced. - The __toString() magic method can no longer accept arguments. - count() vs count_elements() handler resolution rules have changed. (This could potentially break custom PHP extensions.) - The trailing / has been removed from SplFileInfo and other related directory classes. - The new mysqlnd library necessitates using MySQL's newer 41 byte password format. Continued use of the old 16 byte passwords will cause mysql_connect() to produce the following error message: mysqlnd cannot connect to MySQL 4.1+ using old authentication (perhaps an E_WARNING ?) - define_syslog_variables() is deprecated.(not sure if this will throw any E_DEPRECATED or anything) - All ereg functions are deprecated and emit E_DEPRECATED errors. Use PCRE (preg_*()) instead. - The following ini directives will now emit an E_DEPRECATED warning upon startup if they are activated: - define_syslog_variables - register_globals - register_long_arrays - safe_mode - magic_quotes_gpc - magic_quotes_runtime - magic_quotes_sybase Extensions moved out to PECL and actively maintained there - fdf - ming - ncurses c. with changed behaviour - datetime: date/timefunctions will no longer use the TZ environment variable to guess which timezone should be used. - hash: The SHA-224 hash algorithm is now supported. - oci8: Calling oci_close() on a persistent connection, or on a variable that references a persistent connection going out of scope, will now roll back any uncommitted transaction. You should explicitly commit or rollback as needed. Setting oci8.old_oci_close_semantics=On in php.ini gives the old behaviour. - session: Sessions will no longer store session-files in /tmp where open_basedir restrictions apply, unless /tmp is explicitly added to the list of allowed paths. - zend_extension_debug and zend_extension_ts have been removed. Instead use the zend_extension directive to load all Zend Extensions. - zend.ze1_compatibility_mode has been removed. If this ini directive is set to on, then an E_ERROR is emitted at startup. - The default value of session.use_only_cookies has changed to 1 Windows has some changes too, but I think only if you're running pre Windows 2000 will it make a difference. Sorry for re-hashing the entire thing but I think I picked out everything that may conflict with existing code or assumptions on existing code. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Let's put it this way: MVC frameworks with namespaces are going to change a lot. The architecture can be made much cleaner and class names won't have to be so long (Zend_Db_Adapter_Db2_Exception), for instance. The design part of coding is __VERY__ important, and this changes are specially for that. See PHAR extension, which will be enabled now, which allows for easier distribution of software. And closures, which simply have so many uses in design and save you from clustering your code with too many function names. Sure, it doesn't change the language, and it doesn't really break apps that were written in PHP 5.2, but if you're going to design an application, thinking about this options is very useful. Too bad we don't get Traits yet =( Horizontal re-use is very nice. Robert Cummings wrote: Per Jessen wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. Does it _really_ matter which one? I can't imagine there are that many revolutionary changes in a dot-release. Given the naming of PHP versions of PHP-x.y.z, I would agree that not much changes between versions at the .z level. But at the .y level there are usually significant changes. Coming to a PHP 5.3 near you are the following notable features: - namespaces - closures - late static binding - garbage collector to handle cyclic references - PHAR - goto I hadn't actually seen/studied the list, but apart from the goto, I don't consider any of those revolutionary :-) /Per
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Robert Cummings wrote: Michael A. Peters wrote: Manuel Aude wrote: I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks) and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my plans of teaching PHP 5.2 are starting to change, and I think it's a good idea to teach them 5.3 already. While the majority of the students use Windows, I'm aware that a vast amount will be using Ubuntu/Debian (and some use Gentoo, Fedora and Arch) distributions of Linux, so I'm hoping there won't be too many problems on installation. I don't want to waste the entire first class fixing installation problems, because that kills the student's motivation. The course starts on August, but I'm preparing it during the last two weeks of July. You think that installation packages will be bulletproof by then? Or should I just teach 5.2 and wait for another semester before starting on 5.3? I mean, most hosts will remain with PHP 5.2 for the rest of the year, so I'm a bit confused on what I should do. I'm just a university student that wants to spread PHP, for I've been using it for many years now =) Thanks for the advices, Mamsaac Many hosts are still on php 5.1.x (IE RHEL based hosts). I would be worried that many popular classes and apps might be quirky under 5.3. I've not played with it at all, and probably won't for some time, but I've been bitten by that more than once. Nice thing about 5.2.x as far as linux goes anyway, installing it is cake from the package repositories. Using package repositories for php installs is suggested as security fixes can be updated with ease. As someone running a newer version of php (5.2.9) than what my distro ships with, here are some of the issues: A) I needed to create packages so that I could RPM install various stuff, like Squirelmail, etc. - and get the security updates for them from my OS vendor (CentOS or EPEL repods). So to do that, I used the Fedora src.rpm. B) When building php rpm's on my system, the %check portion of the spec file (runs make test I believe) fails sometimes if there is an existing php install. To solve that, you have to build it in mock. C) Mock needs a lot of disk space and will download a lot of packages, if you don't local mirror the update repositories, it can be really time consuming. Furthermore, occasionally the build list for mock is broken making it un-usable for package building. I have to use 5.2.x because I need a pecl extension that does not work with 5.1.x - and building rpm myself lets me add suhosin patch (to the fedora spec file) but unless your Linux students want to do absolutely everything php by source and not have anything installed from the package managers that rely on php, I would highly suggest that they use whatever version of php their distro of choice has in its stable repositories. -=- Since you are teaching students, one pet peeve of mine that I see in web app after web app after web app - they have an admin interface that writes a php file which the app then parses as php. Often they even instruct the person installing the web app to have 777 permissions of directories and/or files within the web root. There's a better way. Either store the configuration settings in a database (obviously can't store database connection setting in the database ...) or store them in an xml file, not php. You can write and read the xml file with any number of existing php functions. And the config file should not be in the web root, nothing the web server can write to should be in the document root. Applications (like Gallery and I think joomla and wordpress) often want write permission to the document root so they can have a web interface to install/update their modules - but it creates a security risk. It's better to install the modules you want from a distro vendor repository so you can keep them up to date that way, and hence, it's better to use a packaged php install so that the dependencies are met. Sorry for rambling, but the trend of web server having write permissions to files the web server then executes (and often in the web root) is a trend that needs to stop. So flunk the students that do it ;) And how do you propose people get around open_basedir restrictions which is common in many Plesk environments? There is nothing wrong with having the above mentioned write access if it is properly protected. Nothing wrong other than any vulnerability in apache (or a module apache loads or cgi/server script code) that allows a malicious user to write data as the apache user can now do so inside the web root where they can then request it causing php/perl/python/whatever to execute the code they just wrote. Every single web host I have ever used that has a shell account given me a directory that is not inside the web root. IE my login home dir might be /srv/www.mydomain.com/ The documentroot would likely be
Re: [PHP] I've some doubts if I should go with 5.2 or go already with 5.3 (for a course)
Bob McConnell wrote: I have recently been told that we are switching from compiling Apache, PHP and PostgreSQL ourselves to only using the official RedHat RPMs on our production servers[*]. *snip* [*] No, I don't like this at all. I see it as the antithesis of both the Open Source and Free Software philosophies. It means we give up control of some of the options we were selecting at compile time and have to settle for somebody else's idea of the perfect server. I fully expect it will come back to bite us at some point. It's probably a paid support issue. If they are going with RHEL instead of a free distribution, they probably are doing so for the support RHEL offers. As soon as you modify the applications, Red Hat understandably refuses to support the modified applications, thus neutering the point of using RHEL. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
