Author's credentials: not enough knowledge about PHP's development?
Posted Dec 27, 2006 19:38 UTC (Wed) by denials
In reply to: Author's credentials: not enough knowledge about PHP's development?
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
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
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
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.
to post comments)