My previous article was quite inflammatory: it was a personal rant never meant to see wide dissemination. I make no apologies for its content, however I do apologise to those who came expecting to see a reasoned argument supporting my assertions and came away rightly disappointed. I'll try to remedy that here and perhaps spark a more intelligent discussion than what was had previously.

Before we start, if your comment consists of "you're just a two-bit blogger looking for fame" or some variation of, try to save yourself the pitiful fate of self-fulfilling prophecy. Posting a comment under those pretenses is a bit like trying to put a store out of business by buying all their merchandise. It's probably not going to work. If you don't want me to be famous, go away. It's really for the best.

Part 1: PHP Points the Gun at Your Head

A common adage is that [insert language or tool] will let you shoot yourself in the foot. PHP helps you out even further by just finishing you off for good.

I just thought I'd get that out of the way in case anyone made the mistake of thinking I had softened on my position any.

Let's start out with a list of assumptions, of which I don't think there can be much disagreement

1. PHP is widely assumed to be a good language for beginners.
2. PHP is mainly targeted at web applications
3. PHP has a configuration file with dangerous options in it
4. Many poorly-written PHP applications require that one or more of those options be turned on in order to function.

Whether the designers of PHP intended it to be or not, PHP is widely considered to be a good beginner's language, probably due to its low barrier to entry. Whether they wanted it or not, that's what they've got and this fact must be recognized and accounted for.

Let's go over the various settings in php.ini that can open serious security holes:

1. register_globals - this injects user-supplied data into the global namespace
2. allow_url_fopen - allows remote URLs to be opened as if they are local files
3. magic_quotes_gpc - pretends to protect you from malicious input

Now, before we start, let's just know that these days, PHP ships with these turned off by default. You have to enable them yourself. Exactly how much protection does this provide? Well it would depend on your level of expertise and whether you realized the implications of what you were doing. Many popular PHP apps require that one or more of these be turned on in order to function. If you are a novice PHP programmer (or just a hapless user following installation instructions), then you are quite likely to just do what you are told by people who apparently know more than you (the developers of said PHP application would appear to be experts). And after all, if they were that dangerous, why would the PHP devs provide them in the first place. That's a very good question.

Now, it's been argued that no moderately knowledgable PHP user would fall prey to such well-known exploits. I think the Mambo developers would beg to differ. Mambo, just in the last few months, fell prey to a combination of register_globals and allow_url_fopen which allowed malicious users to overwrite a global variable which contained the name of a Mambo include file and force Mambo to include arbitrary (and I'd expect malicious) PHP code from anywhere in the world and execute it. Now if the PHP experts working on Mambo can't avoid this obvious pitfall, what chance does a beginner have? That's a rhetorical question, btw.

magic_quotes_gpc is a bit more benign, not providing any direct exploits itself, but rather lulling the programmer into a false sense of security. It purports to sanitize user input to help prevent SQL injection attacks and the like. The problem is it only works on a subset of potential malicious input, doesn't deal with two byte characters and also prevents you from doing it right and using prepare() or one of its variants (you get double escaping if you do both, so backslashes appear in your data). Therefore if, magic_quotes_gpc is enabled, the programmer will have to work that much harder to sanitize input. Except of course they probably won't. If you do some quick tests, it appears to work just fine. Most beginners probably wouldn't even do that, but even if they did, there would be little to raise alarms.

Now, if a beginner were just writing their own code, chances are they would not tamper with php.ini. However, I expect that most beginners are going to install one or more existing PHP applications: a blog, a bulletin board... whatever. There's at least a respectable chance that one or more of these applications will want one or more of those settings on in order to function. The stage is set for that user to unwittingly write exploitable code.

If PHP is to truly be a beginner's language (or apparently a language for anyone, judging from the Mambo exploit), then it needs to be a little more difficult to point the gun at your head. Ideally those options would just be removed altogether from PHP. If for some unfathomable reason this can't be done, then perhaps leaving them as compile-time flags would be slightly better (although still not a good idea IMO).

We are talking about a language, targeted at beginners, interfaced via the most hostile environment possible (the internet), with all the cards stacked against the programmer. What could possibly go wrong?

NOTE: I've just migrated a ton of old articles from Frog (the old blogging software I was using) to this blog and I've yet to convert the comments to the new markup format. Also I deleted a shitload of spam and idiotic comments, so if I accidentally deleted yours, sorry. If you were a spammer or shithead, not so sorry. That should explain any disjointed comments though (and no, I didn't delete all the negative ones, just the ones that added so little as to not be worth the 50 or so bytes of bandwidth they cost).

Please read the latest article before flaming this one. This one will still be here when you get back. I promise.

Open source software has fought a long battle to get where it is today, and at least 3/4 of the so-called LAMP (Linux, Apache, MySQL, PHP) stack are under vigorous attack by many, myself included. Why?

I can't speak for everyone, or for that matter, anyone but myself, but I'm good at doing that so here goes.

I'm quite opposed to using MySQL and PHP, and I'm none too fond of Apache. Anyone who knows me or happens into a conversation with me about development quickly learns of my distaste for these particular projects. To be fair, Apache is the least problematic of the three and if there were no alternatives, I'd use it without a lot of complaint.

MySQL and PHP, on the other hand, really raise my ire. Both of them have two major problems:

1. Bug ridden (by this I am including both misfeatures as well as actual bugs).
2. They encourage bad habits.

I'll start with MySQL. I learned databases on MySQL and used it for several years. Then I discovered PostgreSQL and realized that in fact, I'd learned nothing of databases. For years the MySQL developers were quite vocal that things like referential integrity, transactions, subselects, etc were little more than baggage that could be done better another way. They were after speed, pure and simple. Fair enough, in some respect, since the job MySQL was originally developed for didn't require any of those things. The problem is that a whole generation of database programmers believed them, despite the fact that their applications did require those things. Someone in authority told them they didn't and they bought it (and still buy it). Let me clue you in: you need these things or you need to let someone else handle your database work for you.

Another nit I have with MySQL is the ever-changing ways you must interact with it. Some versions have certain command-line flags, and later versions will ignore those flags (or fail if you pass them),

IMO, MySQL once filled a niche (cheap data store) that today is better filled by SQLite but has moved out of it into a area where it doesn't compete nearly as well (that of an enterprise database) and no longer fits in either. If you need a dumb data store, use SQLite. If you need a FOSS database, use PostgreSQL. They cost the same as MySQL (free) and each does a better job of doing what it was designed for than MySQL.

PHP is another sore spot for me. I've gotten to the point that not only will I not write PHP code, I won't even run applications written in PHP (my long search for decent blogging software was due to the restriction that it not be written in PHP). At some level PHP is a great language because the entry cost is so low. Not so much because the language is so particularly friendly, but because it was designed to work in an extremely simple environment (the web) and because it's quite possible to learn PHP incrementally by intermixing it with HTML. So what's the problem? Well, first of all, as anyone who's done much web programming will tell you, mixing code with markup is not a good thing if you care about maintenance or extensibility. The very thing that makes PHP a great language for beginners is the very thing that makes it a bad language for beginners. At some point they will have to unlearn those habits, except that usually they don't. Also, because it's so easy to whip out a quick PHP webapp, many, if not most, PHP programmers fail to delve very deep into the realm of programming, preferring to sit at the edge and reap the benefits without the work (I'm not talking about coding work, rather the work of understanding your field). PHP programmers practically popularized the most common attack in the world, the SQL-injection attack. Not only is it the most common, it's the most easily avoided. That's how shallow most PHP-programmer's knowledge is. "Professional" programmers are still assembling SQL queries by concatenating strings.

PHP and MySQL are this generation's BASIC, the language that was described thusly by the Free Online Dictionary of Computing

BASIC has become the leading cause of brain-damage in proto-hackers. This is another case (like Pascal) of the cascading lossage that happens when a language deliberately designed as an educational toy gets taken too seriously. A novice can write short BASIC programs (on the order of 10-20 lines) very easily; writing anything longer is (a) very painful, and (b) encourages bad habits that will make it harder to use more powerful languages well. This wouldn't be so bad if historical accidents hadn't made BASIC so common on low-end micros. As it is, it ruins thousands of potential wizards a year.

Replace BASIC with PHP or MySQL (and "low-end micros" with "cheap hosting") and you've got today's most common programmer. Worse, the most common programs in existence today mix the two in a brain-freezing mixture of stupidity.

MySQL and PHP have helped quite a bit in bringing open source into the mainstream. Let's thank them for that and move on, graciously ignoring the millions of minds they've destroyed.