- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Interview with PHP Expert Ivo Jansch
|
|
|
Comments (33)
13 earlier comments in the full thread.
Avoid repeating herself? Typically one doesn't reference your own writing when trying to support your own arguments. I just wonder why you, Sander, an editor on this site, aren't doing anything about it. It makes this site look bad.
The fact is that someone just reading the site won't know who is who. What Carla did is clearly wrong and I called her out on it. I will continue to point these things out as long as it continues to occur.
I don't kill trees, so I don't publish books. I've found man pages more useful, fWIW.
The fact is that someone just reading the site won't know who is who. What Carla did is clearly wrong and I called her out on it. I will continue to point these things out as long as it continues to occur.
I don't kill trees, so I don't publish books. I've found man pages more useful, fWIW.
@pat: I've done the same thing. I know exactly why she does it, Sander is right, and if that isn't good enough for you (and since when do YOU run this site?), go whine up a tree.
@pat -
> Typical Tuxchick argument, php is bad and here's an article written by "Carla S." with why it is bad. What is not said is that Tuxchick is Carla S. alter ego, her secret identity,
That's no secret, all the regulars know that carla is tc. But if you have a gripe with her, why not pm her directly instead of broadcasting on the forum?
> Typical Tuxchick argument, php is bad and here's an article written by "Carla S." with why it is bad. What is not said is that Tuxchick is Carla S. alter ego, her secret identity,
That's no secret, all the regulars know that carla is tc. But if you have a gripe with her, why not pm her directly instead of broadcasting on the forum?
For the record, my argument with tuxchick was argument in the Socratic sense, as imperfect as my attempt at that may have been. In no way was it intended to be a personal attack on her or her credentials. In fact, I went through and read many of her references for that article which made some very good and valid points. However, there were no side-by-side dissections of the alternate technologies proclaimed as "superior".
Wow, that sure brought out the trolls. But not a single word refuting my assertion that PHP is unsafe at any speed. tuxtom and pat, all the smoke and mirrors in the world won't fool anyone- it just proves you have no knowledge of the subject.
...as she posts on a PHP board...
Poor tuxtom, you think that ranting about anything and everything, rather than directly addressing the subject, will fool people into thinking you have a point.
There is nothing subjective about my claims that PHP is inherently unsafe, and you have said nothing to counter that, but instead dredge up goofy things like elitism and the Internet crashing to a halt and every scripting language has flaws and yadda yadda. I linked to some specific descriptions of PHP's weaknesses and problems, and a number of articles that spell out a lot of reasons why it's fatally flawed. You haven't answered any of those, but just gone on your usual tangential rampages. It's possible that I'm wrong, and that PHP is not less safe than the alternatives. But you haven't presented anything to show that.
The OWASP site is full of great information on Web security. Here is yet another informative page on PHP problems, which persist in version 5: http://www.owasp.org/index.php/PHP_Top_5 There is a lot at stake in Web security. Your blaming the messenger doesn't disprove anything I've said.
There is nothing subjective about my claims that PHP is inherently unsafe, and you have said nothing to counter that, but instead dredge up goofy things like elitism and the Internet crashing to a halt and every scripting language has flaws and yadda yadda. I linked to some specific descriptions of PHP's weaknesses and problems, and a number of articles that spell out a lot of reasons why it's fatally flawed. You haven't answered any of those, but just gone on your usual tangential rampages. It's possible that I'm wrong, and that PHP is not less safe than the alternatives. But you haven't presented anything to show that.
The OWASP site is full of great information on Web security. Here is yet another informative page on PHP problems, which persist in version 5: http://www.owasp.org/index.php/PHP_Top_5 There is a lot at stake in Web security. Your blaming the messenger doesn't disprove anything I've said.
Quoting:I linked to some specific descriptions of PHP's weaknesses and problems, and a number of articles that spell out a lot of reasons why it's fatally flawed.I have openly acknowledged those. How about you put those in context by applying the same scrutiny to the alternative technologies that you are recommending rather than just going off on a unilateral "rampage" against PHP? After all, it is you who are arguing that there are "superior alternatives". Prove it! Chopping down an oak tree doesn't make the other species in the forest inherently better.
Quoting:You haven't answered any of those, but just gone on your usual tangential rampages.Ditto. Your modis operandi seems to be to send links referring to the analyses of other people rather than formulate an argument of you own in the context of the discussion. Referring to and paraphrasing other peoples texts is hardly noteworthy.
Quoting:Poor tuxtom, you think that ranting about anything and everything, rather than directly addressing the subject, will fool people into thinking you have a point.Right back at ya, babe. I'm not trying to fool anybody. You are smugly discounting PHP without a similar critique of the weaknesses of any of your proposed alternatives. Are we just to take your word for it? Personally, I think you should vote with your feet and refuse to use any site that runs PHP. That would present a stronger case to the rest of us. You talk the talk. Are you willing to walk the walk?
(Don't worry, PHP will still be here en force should you decide to return.)
Quoting:But not a single word refuting my assertion that PHP is [inherently] unsafe.
Fine. I'll counter. Let's start with http://www.enterprisenetworkingplanet.com/netsecur/article.p... in which your first point is:
Quoting:When you peek under the hood of PHP, it's not a pretty sight. It's full of cruft and chaos [...] this is an obvious recipe for programmer errors. One of the most common security holes is unvalidated input- all user input must be mistrusted, but PHP doesn't have much in the way of tools to help with this, so you have to write your own validation routines.
This doesn't make PHP inherently unsafe. It just makes it harder to write bug-free PHP applications. It's a matter of programming skill, not inherent flaws in the implementation of PHP itself. You can argue that it's harder than it should be, given the large amount of newbie programmers attracted to the language. That would be a valid point. But there aren't flaws in PHP itself that prevent you from writing secure code in it.
By the way, there are excellent PHP tools for input validation. Check out the PEAR repository, specifically http://pear.php.net/packages.php?catpid=50&catname=Validate
Quoting:When you run PHP as an Apache module by using Apache's mod_php, PHP inherits all the credentials of the Apache process.
That's not a PHP issue but a server configuration issue. As you pointed out yourself shared hosters should use suEXEC or CGIWrap. Professional sysadmins should be aware of this issue. There's no excuse. The same goes for hosters not keeping their PHP updated. If your sysadmin is crap, Ruby, Python or Perl won't save you.
Carla, your doom and gloom about php does a HUGE disservice to FOSS. Just more FUD that the Microsoft sales people can show there clients, "See, even the FOSS people don't like PHP, .NET is much better.".
LXer is^H^H has becoming a very good source of FOSS on FOSS FUD. This place is more like a high school clique then an open community of people interested in FOSS.
LXer is^H^H has becoming a very good source of FOSS on FOSS FUD. This place is more like a high school clique then an open community of people interested in FOSS.
Sander, you make some good points, especially the one about mod_php. However, the real meat is in the links at the end of the article. They've been there all along for anyone to read. Here are some highlights- this is just a small sampling:
==== -Poor security, and poor response to security issues. This is a large and detailed topic, but regardless of whether it's caused by inexperienced programmers or by PHP itself, the amount of PHP-related exploits http://milw0rm.com/webapps.php is rather high. And according to a PHP security insider http://www.heise-security.co.uk/news/82500 , the effort is [url=futilehttp://blog.php-security.org/archives/61-Retired-from-securityphp.net.html]futilehttp://blog.php-security.org/archives/61-Retired-from-...[/url] .
-There are thousands of symbols in the PHP namespace. Cleaner languages only have a few dozen. "Everything is built in" just means it has way too many functions in its core, especially since many are minor variations of each other.
-No consistent naming convention is used. Some functions are verb_noun() and others are noun_verb(). Some are underscore_separated, while others are CamelCase or runtogether. Some are prefixed_byModuleName, and others use a module_suffix_scheme. Some use "to" and others use "2". And if you take a random set of ten library functions, chances are half a dozen different conventions will be included.
-Many parts of PHP either deviate from standards, or otherwise don't do what users would expect. For example, exec() returns the last line of text output from a program. Why not return the program's return value, like every other language does? And further, when would it ever be useful to get only the last line of output? Another example: PHP uses non-standard date format characters.
-The documentation... ... is often incorrect or incomplete, and finding relevant information tends to require reading pages and pages of disorganized user-contributed notes (which are incorrect even more often) to find the details the documentation left out. Sometimes really important details are left out, such as "this function is deprecated -- use foo() instead". ... is (as of PHP 5.1.2) not included with the source, nor typically installed along with the binary packages. Downloadable documentation is available, but does not match the docs on PHP.net. Specifically, it leaves out all the user-contributed notes, which are important because of reasons mentioned above. ... is not built in. You can't just point an introspection tool at a PHP module and get usage information from it.
-Magic quotes (and related mis-features) make data input needlessly complex and error-prone. Instead of fixing vulnerabilities (such as malformed SQL query exploits), PHP tries to mangle your data to avoid triggering known flaws. The server-wide settings in PHP's configuration add a lot of complexity to app code, requiring all sorts of checks and workarounds. Instead of simplifying or shortening code (which the features are supposed to do), they actually make the code longer and more complex, since it must check to make sure each setting has the right value and handle situations when the expected values aren't there. PHP's database libraries are among the worst in any language. This is partially due to a lack of any consistent API for different databases, but mostly because the database interaction model in PHP is broken. The SQL injection issues in PHP deserve particular attention. This amusing exchange http://it.slashdot.org/comments.pl?sid=191584&cid=15742484 explains a bit better...
====
In a nutshell- unsafe at any speed.
==== -Poor security, and poor response to security issues. This is a large and detailed topic, but regardless of whether it's caused by inexperienced programmers or by PHP itself, the amount of PHP-related exploits http://milw0rm.com/webapps.php is rather high. And according to a PHP security insider http://www.heise-security.co.uk/news/82500 , the effort is [url=futilehttp://blog.php-security.org/archives/61-Retired-from-securityphp.net.html]futilehttp://blog.php-security.org/archives/61-Retired-from-...[/url] .
-There are thousands of symbols in the PHP namespace. Cleaner languages only have a few dozen. "Everything is built in" just means it has way too many functions in its core, especially since many are minor variations of each other.
-No consistent naming convention is used. Some functions are verb_noun() and others are noun_verb(). Some are underscore_separated, while others are CamelCase or runtogether. Some are prefixed_byModuleName, and others use a module_suffix_scheme. Some use "to" and others use "2". And if you take a random set of ten library functions, chances are half a dozen different conventions will be included.
-Many parts of PHP either deviate from standards, or otherwise don't do what users would expect. For example, exec() returns the last line of text output from a program. Why not return the program's return value, like every other language does? And further, when would it ever be useful to get only the last line of output? Another example: PHP uses non-standard date format characters.
-The documentation... ... is often incorrect or incomplete, and finding relevant information tends to require reading pages and pages of disorganized user-contributed notes (which are incorrect even more often) to find the details the documentation left out. Sometimes really important details are left out, such as "this function is deprecated -- use foo() instead". ... is (as of PHP 5.1.2) not included with the source, nor typically installed along with the binary packages. Downloadable documentation is available, but does not match the docs on PHP.net. Specifically, it leaves out all the user-contributed notes, which are important because of reasons mentioned above. ... is not built in. You can't just point an introspection tool at a PHP module and get usage information from it.
-Magic quotes (and related mis-features) make data input needlessly complex and error-prone. Instead of fixing vulnerabilities (such as malformed SQL query exploits), PHP tries to mangle your data to avoid triggering known flaws. The server-wide settings in PHP's configuration add a lot of complexity to app code, requiring all sorts of checks and workarounds. Instead of simplifying or shortening code (which the features are supposed to do), they actually make the code longer and more complex, since it must check to make sure each setting has the right value and handle situations when the expected values aren't there. PHP's database libraries are among the worst in any language. This is partially due to a lack of any consistent API for different databases, but mostly because the database interaction model in PHP is broken. The SQL injection issues in PHP deserve particular attention. This amusing exchange http://it.slashdot.org/comments.pl?sid=191584&cid=15742484 explains a bit better...
====
In a nutshell- unsafe at any speed.
We'll pull over for you to get out.
Thats funny, I read the php.net home page and I see security addressed in every release, just like every other FOSS project. Just more FUD from the lxer department of FUD.
Quoting: Just more FUD from the lxer department of FUD.
I may not agree with all of Carla's opinions, but she is no spreader of FUD. That's out of line and dead wrong.
This page has some useful comparisons to Perl:
http://tnx.nl/php
More detailed analysis of PHP: http://thwartedefforts.org/problems-with-php/
Which were all linked to from my article.
More detailed analysis of PHP: http://thwartedefforts.org/problems-with-php/
Which were all linked to from my article.
@tc -
those are some valid points in your links, but a lot of them come down to taste, and some I'm doubtful of (e.g. "perl is faster than php" - in what context, how measured?) Sure, php is messy, sort of like perl to the extreme, but you can do a lot of cool stuff with it.
Keep in mind that a disciplined programmer will write better code than a beginner. and php is evolving and improving, so in time, all the major objections will likely be addressed.
those are some valid points in your links, but a lot of them come down to taste, and some I'm doubtful of (e.g. "perl is faster than php" - in what context, how measured?) Sure, php is messy, sort of like perl to the extreme, but you can do a lot of cool stuff with it.
Keep in mind that a disciplined programmer will write better code than a beginner. and php is evolving and improving, so in time, all the major objections will likely be addressed.
It's true herzeleid, that a skilled person with crummy tools will often outperform an inexperienced person who has great tools. OTOH, someone who clings to inferior tools when there are all kinds of excellent free alternatives might be considered, what...blindly stubborn? Foolish?
My points are very basic:
-PHP is too inherently flawed to trust. How many exploits is it going to take to get people's attention? It can't work both ways- it can't be both inviting and wonderful for noobs, and then all the fault of these poor noobs for its defects.
-This whole discussion, with few exceptions, is like being on a Windows forum- "PHP is too secuar and totally awesome! It's dumb lusers who cause the problems!"
LAMP security is tricky enough, with data validation and cross-site scripting exploits being two of the biggest chronic headaches. I don't see why any responsible developer would cling to flawed tools (don't forget the upgrading and version sync problems, which makes routine maintenance a total nightmare) when there are several excellent, superior alternatives. To me it's typical short-term microsoftian thinking: make it pretty and sort-of easy, don't look under the hood, and don't think of the long-term consquences.
I'm done supplying links and references, as it's a waste of time. The only reason I'm still posting is trolling and deliberate dimwittery offend me. (No, not you!) I don't care what other people use. Anyone who is honest enough to face the facts knows what's what. I haven't seen one single item in this whole thread to counter what I've been saying. I've done my homework, and I've dug into PHP guts and seen it for myself. Some informed debate, rather than emotion and trolling, would be awesome, but I'm not holding my breath.
My points are very basic:
-PHP is too inherently flawed to trust. How many exploits is it going to take to get people's attention? It can't work both ways- it can't be both inviting and wonderful for noobs, and then all the fault of these poor noobs for its defects.
-This whole discussion, with few exceptions, is like being on a Windows forum- "PHP is too secuar and totally awesome! It's dumb lusers who cause the problems!"
LAMP security is tricky enough, with data validation and cross-site scripting exploits being two of the biggest chronic headaches. I don't see why any responsible developer would cling to flawed tools (don't forget the upgrading and version sync problems, which makes routine maintenance a total nightmare) when there are several excellent, superior alternatives. To me it's typical short-term microsoftian thinking: make it pretty and sort-of easy, don't look under the hood, and don't think of the long-term consquences.
I'm done supplying links and references, as it's a waste of time. The only reason I'm still posting is trolling and deliberate dimwittery offend me. (No, not you!) I don't care what other people use. Anyone who is honest enough to face the facts knows what's what. I haven't seen one single item in this whole thread to counter what I've been saying. I've done my homework, and I've dug into PHP guts and seen it for myself. Some informed debate, rather than emotion and trolling, would be awesome, but I'm not holding my breath.
Quoting:Developers who are skilled in Perl, Python, or Ruby are going to have plenty of 'speed to market', and they're going to have stronger, maintainable sites. The supposed speed advantage of PHP is only for novices who want to fling something up quickly, with minimal study. After that initial fling-up, PHP loses all advantages- it's harder to maintain and scale, and trying to keep the beast secure is nearly impossible.These are your original points which you claim are very basic. You have provided many examples of where you claim PHP is "fatally flawed"...most well known and avoidable and aren't being contested. However, you have failed to show any evidence that the other language platforms are stronger, more maintainable, just as fast to market, more scalable or more secure than PHP. Your fundamental premise isn't that PHP has so many weaknesses, it's that these other technologies are so superior in these areas.
Quoting: The only reason I'm still posting is trolling and deliberate dimwittery offend me.Some might observe that continuing to post negative commentary about the subject without backing up your original claims (reiterated in the last paragraph) on a board powered by the very technology you hold contempt for is trolling. You have really been trying to bait us into arguing over minute details which are well-known and have not been contested, yet you still refuse to look outside those encapsulated points and address the breadth of your original statements.
Quoting:PHP is too inherently flawed to trust.
It's not inherently flawed. If it were, it would be impossible to write a non-trivial secure application in PHP. It's not impossible. Harder that it should be pethaps, but far from impossible. Calling PHP inherently flawed is like calling C inherently flawed. Both languages are easy to learn and hard to master. Both are difficult to write secure code in. The main difference between C and PHP from a language point of view is that there are a lot of newbies promoting PHP to other newbies.
Of all the links and references you provided, none discussed security issues in the language itself and one referenced it (month of the PHP bugs). Everything else is about configuration (which has drastically improved out-of-thebox. register_globals has been off for ages. The URL wrappers are off. Even magic quotes is off) or about applications written in PHP.
You're free to argue that writing secure PHP code is harder than it should be. That there are many inconsistencies in the core. I'd agree with you. I'd support any effort to make writing secure code easier even if it breaks existing applications. But all that does not make PHP *inherently* insecure, which is what you've been claiming this entire thread and which I find a baseless claim.
Quoting:The only reason I'm still posting is trolling and deliberate dimwittery offend me. [...] Anyone who is honest enough to face the facts knows what's what. I haven't seen one single item in this whole thread to counter what I've been saying. [...] Some informed debate, rather than emotion and trolling, would be awesome, but I'm not holding my breath.
I take offense at those statements. Keep your ad hominem attacks to yourself if you really want an informed debate.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
Tone it down, pat. Everyone here knows that tuxchick is Carla. She simply links to an article to avoid repeating herself. Why make the same point twice?