Stuart Herbert

… but sometimes there’s just nothing else to be done.

I’ve justed package masked dev-php/asp2php. This package contains two confirmed buffer overflows, which can be used to maliciously install files using the permissions of whoever runs the script. This fault was first discovered a couple of weeks ago, and is one of the now infamous 44 problems discovered and reported by D. J. Bernstein.

It’s a buffer overflow. They happen to even the best of packages. Normally the fault gets fixed, a new version comes out, and life goes on. But not in this case.

Unfortunately, the author of asp2php either doesn’t understand that it is his code which contains the fault, or he simply doesn’t care. Honestly, I don’t know which. But either way, his denial leaves Gentoo with a problem. It leaves Gentoo with three choices:

1. Continue distributing the package, but warn users that it contains known security holes. Well, I’m not going to say that this should never happen, but it’s not something any responsible distribution can do regularly. There’s a trust thing between users and their Linux distributions, and part of that is being able to trust that the packages a user installs don’t contain known security holes.
2. Fix the package ourselves, and (hopefully) get the patch accepted upstream. This does happen sometimes, but does Gentoo really want to be stuck having to patch a package because the original author doesn’t want to fix his own code? What’s going to happen the next time? Or the time after that?
3. Remove the package, and publish a security advisory advising everyone to uninstall the package. It’s the saloon of last resort, but it’s the responsible thing to do with abandonware. An upstream package with known (and unfixed) security holes is a form of abandonware. Exploits allow machines connected to the Internet to be turned into zombies; machines used as relays to send spam (or worse) to other machines, and ultimately to me and you. Security matters, and anyone who has a cavalier attitude towards it should not be writing or selling software.

Let’s take a look at some of the nonsense you can find about PHP 5 around the Net …

(more…)

Thanks to my nice new shiny toy (more on that shortly), I\’ve been able to get CLI and Apache 1/2 mod PHP 5 into Portage. The CLI stuff works great - partly because I\’m using it daily atm. With the mod_php5 package, all I\’ve done so far is proved that phpinfo() works as expected.

Neither package handles dependencies properly yet, simply because it takes a long time to work through the best part of 100 different configuration options supported by PHP 5\’s configure script. But we\’ll get there.

Best regards,
Stu

… is that it\’s actually quite frightening just how much PHP programmers sometimes need protecting from themselves.

I\’m pretty sure work will be interested in this right now, so it may be turning up in Gentoo during the week. I\’ve patched my local copy of mod_php, and so far my site seems to be running without any problems

… because the support for XSL in PHP 4 is nothing to be proud of.

In PHP 4, there are two XSL processors to choose from.

• There\’s libxslt, the XSL library for the GNOME desktop. It\’s the de-facto standard processor in the open-source world, and has a reputation for reliability.
• And there\’s Sablotron from the Ginger Alliance. It\’s earned a reputation for performance - and instability.

Neither processor is as solid as one would wish for. At work, we recently looked at switching to libxslt - but unfortunately it couldn\’t evaluate our XSL templates the way we expected them to be evaluated. The changes required didn\’t seem major, but the decision was taken that it\’s something that has to wait for another day. After all, without in-depth testing, we don\’t know just how many changes will be required before our XSL templates will work with libxslt. And yes - we\’re fairly confident that our XSL templates are standards-compliant in the areas where we had problems with libxslt.

Sablotron, on the other hand, is something that I\’d love to be able to switch away from. Whether it\’s on Windows or Linux, I\’ve always found it pretty hard work to not crash Sablotron at some point or another over the years. To be fair, the finger of blame can probably be pointed at some of the later versions of the expat library that Sablotron relies on to parse XML; but I\’m sorry, I don\’t really care which is at fault. I have better things to do with my life than look at yet another core dump that happened whilst Sablotron was working. I\’m well aware that plenty of people have found Sablotron stable and robust, so of course you should try Sablotron for yourself, and not just take my word for it.

The PHP interfaces to both processors also have their relative weaknesses.

For myself, the major shortcoming of PHP 4\’s interface to libxslt is the lack of a documented ability to set the base URI for external entities that start with a \’/\’. I\’ve quickly skimmed through the domxml extension\’s source code, and didn\’t spot an undocumented procedure either. This means that we can\’t use PHP 4\’s libxslt support to drive the Gentoo Linux website. Anyone else running a site driven off static XML and separate XSL files is going to have the same problem.

So what about Sablotron? +1 here, because PHP 4 does provide a function for setting the base URI for external entities. But the score is quickly into the red Our Gentoo files expect XSL\’s document() function to work relative to the directory that the XSL file is in - and not relative to the base URI. Who is right? I don\’t know right now - but I know which is going to be the easier to sort out. But the biggest problem is that I couldn\’t figure out a way to get the PHP 4 interface to Sablotron to use whatever XSL stylesheet is referenced in the XML file. It seems that you have to pass Sablotron both an XML file and an XSL file, or else it won\’t process. That\’s never going to fly, so Sablotron is sacked too.

Where does that leave me? Tired, disappointed, a little frustrated - and a little embarrased too. I\’m embarrased that PHP 4\’s support for XSL is not up to the job of helping serve up static XML pages that reference static XSL pages. For dynamic XSL processing, these problems don\’t exist. But for now, on Gentoo, we won\’t be switching to PHP to process our XML for our readers.

Best regards,
Stu

I\’ve just committed an ebuild for mypictures. It\’s a simple but effective photo gallery. I\’m using it myself for my own photo gallery. If you need something to publish your photos, give it a try.

One of the things in life that I\’ve never been able to understand is the amount of outright hostility there is against PHP.

I can understand there being hostility against a lot of the software floating around that\’s been written in PHP. The PHP community has a well-earned reputation for badly designed and buggy software, and much of this is because many of the people writing PHP do not have a software engineering background. That said, there\’s a huge amount of excellent PHP software too, and the improvements that PHP 5 is going to deliver can only help. Exceptions will finally leave PHP programmers with no excuses (except a lack of professionalism) for producing software that isn\’t robust. And interfaces will (I hope!) finally encourage PHP programmers to standardise how important tasks such as authentication are done, so that it\’s a lot easier to aggregate two or more separate PHP programs into a single site.

The hostility I keep coming across is at the very idea of using PHP.

A lot of it is sheer ignorance from people who should know better - people who are happy to pass themselves off as \’experts\’ in one field or another. They\’ll happily sit in IRC chat rooms, and proclaim that PHP suffers from all sorts of imaginary evils. They\’re not speaking from their own experience - they never use PHP. So where do they get these impressions from? I actually know people who go out of their way to avoid using PHP and software written in PHP. What is it that they are so afraid of?

I have no idea.

It\’s true that many programmers - and many organisations - get hung up on the idea that the same technology should be used everywhere. No matter what the cost, no matter what the problems. Some companies - and I\’ve been unfortunate enough to work for at least two firms where this has happened - refuse to change technologies even when the end-product is suffering.

Any entrenched position on technology just turns today\’s leaders into tomorrow\’s dinosaurs.

There\’s no reason to be afraid about accepting PHP into the enterprise. Or into your programmer\’s toolbox. The runtime environment is simple to deploy, has zero maintenance, and is robust. Security problems are rare, and are quickly addressed when they are reported. Performance is good (although it could always be better) and runtime overheads are low. PHP is certainly suited to high traffic / high volume sites, something that has been proved time and time again. The language itself is sensible, with a syntax that most experienced programmers will have no trouble at all in picking up. One really practical feature is that you can mix both object-orientated and traditional procedure-based programming as you wish. PHP doesn\’t force you to do things the one way. It comes with a rich runtime API, and probably the best online manual for any programming language in use today. The productivity of PHP programmers is high, and like any language the quality of the code is down to the quality of the programmer at the keyboard.

So the next time you start to say \’No\’ to a PHP solution, take a good look in the mirror and ask yourself whether you\’re one of tomorrow\’s leaders - or one of tomorrow\’s dinosaurs.