User: Password:
Subscribe / Log in / New account

Author's credentials: not enough knowledge about PHP's development?

Author's credentials: not enough knowledge about PHP's development?

Posted Dec 27, 2006 19:38 UTC (Wed) by denials (subscriber, #3413)
In reply to: Author's credentials: not enough knowledge about PHP's development? by erich
Parent article: The state of PHP security

I feel compelled to respond to your comment. In doing so, I hope to better illustrate why I was concerned about the article in the first place.

Sorry, but your post is typical - in lack of hard facts, you attack him because of his CV. Very lame, dude!

A CV is a record of someone's education and experience. The author's CV is probably the hardest set of facts I could use to evaluate his familiarity with the subject matter of his article. There was little evidence on his CV that he had much education in, experience with, or involvement with PHP; therefore, I called his credentials into question.

Then next you go after perl - "see, the dinosaurs are extinct, too, so we can just die as well!".

I used Perl because 1) it is the primary language that the author has experience with and 2) as an example of another popular language used to develop Web applications that suffer from the same security vulnerabilities that similar Web applications programmed in PHP suffer from -- but which does not get nearly as much publicity for those vulnerabilities as PHP applications do.

And the author did pretty much state your opinion in his article, too: "PHP proponents tend to take a 'blame the user' approach that is reasonable in some ways, but fails to recognize some of the inherent issues with PHP itself" - there you go, fits you dead on.

This was not the primary point of my comment. My point was that the author used a quote from 2002 and failed to consider the last four years of PHP development before drawing a damning conclusion from that quote. I provided a quote from the PHP 6 planning process in 2005 that demonstrates that the PHP developers actually have recognized some of the inherent issues with the language and that they plan on doing something about it.

comments skipped, in the interest of being "polite, respectful, and informative" as LWN requuests.

Still, the typical Perl CGI has fewer security issues compared to a typical PHP script out there, so who is the "glass programming language".

Can you point to some "hard facts" that prove your assertion, please?

In the end, I feel that this article was not up to LWN's normal journalistic standards. Stefan Esser's departure from the PHP development team would have been a good opportunity to discuss not only the (to me, at least) interesting and passionate personalities that form the core PHP development team, but also serve as a good jumping-off point to investigate the state of PHP security as it stands in the 5.2.x (current stable) and 6 (development) branches of the PHP language. There is an interesting debate going on right now on the PHP internals mailing list about the possible addition of taint support and its potential roles in PHP security, as well as the relation to the ext/filter support that was added in the PHP 5.2.0 release, and some insights from Rasmus into how Yahoo! plans to use a strict global filter for PHP applications. All of this information is publically available from the archives of the PHP internals mailing list.

The kind of article I have come to expect from LWN would have delved into the current and future state of PHP security, rather than relying on a more than four-year old quote as the sole insight into the state of mind of the PHP development team. I do hope that the author will consider this feedback in his future articles; I'm willing to entertain the possibility that this article was just a one-time lapse of taking the easy way out with a deadline leading up to the holidays.

(Log in to post comments)

Author's credentials: not enough knowledge about PHP's development?

Posted Dec 27, 2006 20:26 UTC (Wed) by jake (editor, #205) [Link]

> There was little evidence on his CV that he had much education in, experience with, or involvement with PHP; therefore, I called his credentials into question.

I guess it isn't clear to me how much experience is required to comment on and have an opinion about PHP security. That being said, you may also wish to consider that 20+ years of developing software in any language is probably enough experience to rapidly understand a new one. I believe my knowledge of PHP is quite broad, but in the end, I don't think it matters to *report* on the language. There are tons of technical journalists who have a great deal less (or no) development experience than I do, but, at least in my opinion, that doesn't mean they cannot report on things and have opinions about them.

Your main problem with the article (other than getting your hackles up because you perceived an attack on PHP) seems to be my use of the 2002 interview. I did think about whether or not to use it. In the end, it seemed so completely mind-boggling to me that the creator of PHP could not see the issues with both register_globals and magic_quotes after *years* of exploits. I am quite glad to hear that he has changed his mind, but it was and is amazing that after mountains of evidence to the contrary, Rasmus still thought those were good features. I thought readers would find this interesting as well.

> I do hope that the author will consider this feedback in his future articles;

I read all the comments on my articles and will definitely consider what you have said. I don't think you make much in the way of substantive complaints about the article; you just wish it had been a different topic (i.e. future PHP security plans). That topic does sound like a good one, perhaps you should contact Jon and see if he is interested in having you write it. If not, I will certainly consider it for a topic down the road.


Thanks for the response

Posted Dec 28, 2006 3:51 UTC (Thu) by denials (subscriber, #3413) [Link]

Thanks for the response, Jake. I can understand that you feel defensive about my comments; I comment because I care about LWN. I suspect that this is just a misstep for you and LWN; but that being said, I'll try to explain why I'm so concerned about what I'm concerned about.

I agree that twenty years of software development can help you get up to speed quickly with a new language's syntax. Understanding a language's syntax, though, does not replace the kind of research that technology journalists do to understand their subject matter before they present their opinions to a trusting audience. In this case, the subject matter is "PHP security", and you've nailed some of the historical design decisions that led to vulnerabilities. However, it is my opinion that you failed to accurately represent the state of PHP security.

My main problem with your article was not that you used an interview from 2002, but that you paraphrased Rasmus's quote from that ancient (by the world of technology measures) interview in an article called The state of PHP security without mentioning that the quote was from 2002. One suspects that most readers would be led into thinking that this statement represents the current state of PHP security:

It is an extremely dubious feature, but one that PHP creator, Rasmus Lerdorf, seems to think should have been left on by default.

I agree that this was an interesting statement, but in the interests of fairness (particularly because you noted how "amazing" the statement was) you should have, at the very least, used the past tense and explicitly noted that the statement was from 2002. And it would have been both appropriate (for on online publication called the Linux Weekly News) and interesting to find out if Rasmus's thoughts on the matter might have changed in the last four or five years -- perhaps even get him to revisit his 2002 quote in that interview. This would have been a reasonable and decent thing to do. As the author of an article that attributed a "mind-boggling" position to Rasmus, you should not have had to hear it from me that he has since changed his mind. It was your duty to your readers to find that out and tell it to them.

You suggested that what I wanted was a different article. Again, I will agree: I wanted a better article, one that fulfilled the promise of the title by reflecting the state of PHP security. To do that, I suggest that you have to consider:

  • where PHP security was (well done)
  • where PHP security is (not so well done; I think everyone would agree that the proliferation of bad tutorials and poorly written applications that unfortunately have "php" in their name is a tough nut to crack, but you failed to mention the addition of the ext/filter module in 5.2.0 that has the potential to either significantly improve the security of PHP applications or become another misadventure in trying to automate security; actually, come to think of it, you missed all of the security changes in the 5.2.0 release notes from back on November 2nd, including disabling (by default) URLs in include, although you can be forgiven for missing the ongoing taint mode discussion as that just cropped up on Dec. 15th)
  • and where PHP security is going (not well done: nary a mention of the readily available PHP 6 plans)

I have no hackles to raise about attacks on PHP in particular. I have developed and maintained applications in C, Java, Perl, PHP, and Python, and have written articles and/or chapters of books about all of these languages, and have spoken at conferences about Perl, PHP, and Python. I'm not a one-trick PHP pony. Having a foot in all those worlds, I will admit that it gets tiresome watching PHP get slagged without substantiating claims simply because it's accepted practice in the unwritten hierarchy of programming languages, and your article did emit a whiff of that attitude. But I primarily care about fairness, balance, and the standards that LWN has set by example in the past. If I was forced to place this article on a journalist quality continuum between "slanderous fiction" on the one side and "shining model of balance and insight" on the other side, I would have to agree that I felt that this article fell more on the negative side of the continuum ("an attack on PHP" as you say) due to the failure to clearly state the date of Rasmus' statement, the failure to follow up with Rasmus or the PHP development team, and the general omission of significant developments in PHP security (whether by design or by lack of research).

I've been an LWN subscriber since 2003 because LWN has an excellent record of hitting the positive side of that journalistic quality continuum. As I said in a previous comment, I'm sure that the quality of this article was just a downward blip due to holiday schedule pressures.

Thanks for the response

Posted Dec 28, 2006 5:37 UTC (Thu) by jake (editor, #205) [Link]

Upon further reflection, the title, which I did suggest, is not an accurate representation of the contents.

PHP 5.2 and 6 are all well and good and I applaud the PHP team for whatever strides they have made security-wise. As I said, it would probably make a nice article. Unfortunately, many apps and hosting sites still only support earlier versions of PHP, some dating from 2002, perhaps. This is, of course, not the fault of the PHP team, but it might have been avoided by taking some of the steps you describe a bit earlier in the development of the language.

I get tired as well of reading SQL injection, XSS, remote file include and other vulnerabilities in PHP apps, in many cases written by people who are trying to get it right. Perhaps my weariness with all of that crept into the article more than it should have.

I appreciate your comments, thanks ...


Thanks for the response

Posted Jan 4, 2007 9:40 UTC (Thu) by appie (guest, #34002) [Link]

With regard to SQL injections, if you don't use an abstraction layer and are using postgresql (applause! :-) be sure to use:
It's available since PHP5.1

And remember to revisit the excellent (!) online PHP manual plus comments every now and then to check for new and improved features.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds