| |||||||||||||
Author's credentials: not enough knowledge about PHP's development?Author's credentials: not enough knowledge about PHP's development?Posted Dec 25, 2006 4:56 UTC (Mon) by erich (subscriber, #7127)In reply to: Author's credentials: not enough knowledge about PHP's development? by denials Parent article: The state of PHP security
Sorry, but your post is typical - in lack of hard facts, you attack him because of his CV. Very lame, dude! Then next you go after perl - "see, the dinosaurs are extinct, too, so we can just die as well!".
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.
"with reasonable default security"
There is more stuff that's wrong with PHP. For example the way it's embedded in HTML, and actually encourages that. People should be offered an easy to use template language (preferrably one where they can edit the HTML with their favourite GUI editor, talking about easy-to-use...) and some variable mapping. Have a look at Kid, Genshi, TAL/METAL, XML::Template (also available for PHP).
Your comparison with perl is very unfair. Perl has been around for even longer than PHP, and it was NOT DESIGNED to be a web development language, but for writing regular applications. It was not designed for security on the web either (though tainted mode is a great feature; just that many people don't know how to use it, just like they don't stop using register_globals). It was designed for chewing texts quickly, with a really compact syntax.
Still, the typical Perl CGI has fewer security issues compared to a typical PHP script out there, so who is the "glass programming language".
/me uses Python for his stuff. Much easier to read than PHP hidden in HTML.
Ruby has some nice sandboxing concept, that sounds useful for secure web programming...
A comment to the meeting notes:
Oh, and Perl doesn't have SQL?
(Log in to post comments)
Author's credentials: not enough knowledge about PHP's development? Posted Dec 27, 2006 19:38 UTC (Wed) by denials (subscriber, #3413) [Link] 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.
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.
jake
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:
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 ...
jake
Thanks for the response Posted Jan 4, 2007 9:40 UTC (Thu) by appie (subscriber, #34002) [Link] With regard to SQL injections, if you don't use an abstraction layer and are using postgresql (applause! :-) be sure to use:pg_query_params() http://www.php.net/manual/en/function.pg-query-params.php 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.
|
|||||||||||||