As most of you hopefully know, a few days ago PHP 4.3.10 and 5.0.3 were released in response to several vulnerabilities that were discovered. Two of those involved bugs in unserialize function that is used to re-create PHP variables based on an encoded string normally generated by serialize() function. This functionality allows storage & retrieval of PHP variables from outside PHP. While these two problems are quite serious, they can normally only be exploited locally, meaning that you'd need an account with access to PHP on the server. However, several applications such as phpBB store serialized data inside cookies meaning that anyone accessing those applications will be able to supply their own serialized string. By tinkering with this string it is possible to make an exploit capable of doing things like theft of passwords. In response to this development phpBB developers decided to put the following statement out "This is not a phpBB exploit or problem, it's a PHP issue and thus can affect any PHP...

A rather educational article came to my attention today reflecting the thoughts of some US citizens about Canada on public television in what one may consider to be major news outlets. While I can only hope this is the opinion of a small minority, even that is a little alarming.

After what seems like months of development a new stable release of FUDforum, 2.6.9 is finally out. This release fixes a fair number of bugs as well as introducing a number of functionality changes. These include series of speed imporvenments for many parts of the forum as well as some optimizations aimed at MySQL 4.1 users specifically. As of 2.6.9 all installation are now capable of generating PDFs based on forum messages thanks to the customized FPFD library bundled with FUDforum. The layout of the PDFs was also improved. All FUDforum users are encouraged to upgrade to this release. The upgrade and installation scripts can be found here.

Many PHP developers, myself included often mention that using PHP that is compiled statically (Apache module) is much (18-30%) faster then the shared module that is normally compiled. This is a rather unusual claim that is often met with much skepticism for a good reason, presense of pic code resulting from a shared build should not cause this, however benchmarks speaks for themselves. Unfortunately finding hard data is rather hard since most of us are rather lazy to spend 30 mins performing the needed tests. Fortunately, George Schlossnagle published the benchmarks he conducted on the matter that conclusively demonstrate that the the static build is much faster. The raw benchmark data can be found here At this time PHP still does not have a no-pic option, so for those of you interested in getting a fair bit of performance from PHP here are the instructions. When building PHP for Apache 1, make sure to configure PHP as a static Apache module and disable the building of CGI and CLI, you will also need...

This afternoon an interesting problem came to my attention. This problem is the result of PHP and mod_perl being used together on Apache server. The full details of the problem can be found [url=http://www.phpbuilder.com/lists/php-install/2003092/0018.php]here[/url]. The quick summary is that if PHP code uses putenv() function it will conflict with mod_perl and cause frequent crashes. The suggested solution is to use the Apache's apache_setenv() function. However, as I found out this does not always work. In my case I need to set the TZ environment variable that allows me to change the timezone. The tricky thing about timezone changes is that after TZ is changed, a libc function tzset() needs to be called to activate the change. PHP's own putenv() calls this function if it detects that the TZ environment variable is being changed, Apache SAPI function apache_setenv() does not. This means that the environment var change does not accomplish the desired goal. Even if I were to modify (tried doing this) the P...