All posts by Matthias Scheler

Flying after 8/10 (part II)

Yesterday we took the flight to Germany from London Heathrow to Frankfurt International. London Heathrow was busy as usual and it took us about 45 minutes to get through the security check. That’s not too bad and I can remember that it took longer on a Friday a few years ago. The restrictions for hand baggage had also been eased and we were each allowed one bag. My backpack (which has traveled with me to the USA, Egypt, Spain and many other place in the past) is unfortunately too big and I left it home. Instead I carried the present, a Chocolade Nemesis cake, in a bag to make sure it arrived in Germany in a presentable (and eatable) state. My wife also left her backpack home because it exceeds the allowed size by a few centimeters. In retrospect she could have brought it because there were definitely people who were allowed larger bags as hand baggage. The shoulder bag she used instead was large enough to put our notebook into it but was of course much less comfortable to carry.

There was also a bright side to all the trouble: there was much more space in the overhead compartments on the plane that what we are used to. And the cake survived the trip, too.

PHP – Pretty Hopeless Programming language?

I’ve updated a package of the NetBSD package source collection today. The package contains a PHP application which surprisingly required a security fix. And I have committed a lot of security updates for PHP based packages to package source recently. And from what I read on the Heise Newsticker it looks like there have been a lot more vulnerabilities in PHP based web applications recently.

The amount of such security holes which are always caused by the same problems (uninitialized variables, cross-site scripting, etc.) make me wonder whether the design of the PHP language is flawed. Yes, there are also a lot of security holes in applications which were writtten in C or C++. But these programming languages are much more versatile and therefore used to solve much more complicated problems.

PHP however is an application language. It was designed to write web applications. And based on great PHP products like WordPress or phpMyAdmin it seems to do that job very well. But it seems that security was not a design goal when the language was created. E.g. being able to assign arbitrary values to variables via parameters embedded in the URL is a really bad idea. Even the ancient cgiparse program which was part of the W3C HTTP daemon distribution was clever enough to prefix all shell variable names to stop a remote client from overwriting important things like the PATH variable.

Perhaps it is time to redesign the PHP language. The new version should not try to be fully backwards compatible. It should instead remove all those features which have caused security problems in the past. That will of course require changing a lot of existing PHP code. But anything else will just result in more problems in the long term.