After a fairly short incubation period, 2.7.0 final is now available for download. Installation Script Upgrade Script The release was made a bit faster then anticipated in response to a rather serious security problem found in the uploaded avatar handling code. All who use FUDforum and allow forum members to upload custom avatars are encouraged to upgrade immediately. The details of the exploit are not being released at this time, but believe me when I say that the problem is quite serious and you should most definitely upgrade if you use the uploaded avatar functionality. Aside from the fix for the security problem, this release integrates a number of other changes and improvements, in particular a much improved in terms of speed forum topic view generation code. The list below inclidues the changes found in the final, that were not present in RC1. Fixed a number of edge cases where E_NOTICE warnings may be generated. Unify SQL error handling. A number of PostgreSQL fixes and computabil...

While on my daily news crawl, I came across a site (http://gdataonline.com/seekhash.php) offering a free and very quick service designed to decode md5 hashes. The principal used here is a dictionary attack; the operators of the site build a reasonably large, 12 million & counting, database of hashes and their corresponding values. All you need to do is specify a hash and if they got it in their database in less a then a second you get to see its corresponding value. While compromising weak hashes via dictionary attacks was never that hard, it did require wasting some time and processing power in application such as John the Ripper (http://www.openwall.com/john/) trying to find the equivalent value. Now, you can do it quite effectively (I’ve tried) via this online tool in fractions of a second. Given that many PHP applications (my own included) store passwords as hashes rather the clear-text, it now raises the needed to encourage users to be a bit more creative with their password strings. Use of high-ASCI...

Came across a rather “interesting” peculiarity in PHP, which affects mathematical operations involving floating point numbers. Before getting into the details, let me introduce you to the problem I was trying to help a friend solve. The goal was to take an arbitrary floating point number, let’s say 1.841243, and convert it to a whole number where decimal points became part of the whole, so 1.8432432 would become 18432432. The first solution was a very simple scriptlet, which if C has taught us anything should’ve worked. [php] $a = 1.8432432; while ((int)$a != $a) $a *= 10; [/php] This code relies on 2 premises, which are true in PHP: 1) Casting a float to an int, results in a drop of decimal points. (Ex. (int) 1.8432432 => 1) 2) By multiplying value by 10, all decimal places will eventually be gone and (float)$a will equal (int)$a. While both premises are true, the above code does not work, in fact, it results an unterminated loop, YIKES! Quick confirmation with C code, included below, re-affirms th...

Yesterday I've discovered an "interesting" implication of using user input inside var_export() and print_r() functions. To those who have never used the two, a brief overview of their functionality. The var_export() function takes a variable and represents the data found within as a valid PHP string. By default this string is dumped to screen, but if you want you can have it be returned as a string, by passing a 2nd optional parameter as boolean TRUE. For example if you wanted to put an array creation code into a file, you'd do something like this: [php] file_put_contents("my_file", var_export($array, 1)); [/php] The print_r() function is similar in function, except the returned data is intended for debugging and not storage. As with var_export() by passing a 2nd optional parameter you can force the data to be returned as a string rather then dumped to screen. Herein lies the problem, when it comes to storing the data, this is done by enabling output buffering of the content without a set buffer size limi...

Finally got a semi-stable internet connection, a pretty amazing thing during a convention of this size. So, while George is serenading the audience with the wonders of DBXML, I get to do a bit of blogging :-). The conference so far is a great deal of fun, had a chance to meet with many developers from other non-PHP projects, which is quite neat as most conferences I have a chance to attend to be PHP specific. The brief talk on performance I gave yesterday went rather well, with probably one of the largest audiences I've had at a conference and seemed to have gone rather well. The slides, to those interested are now available online (just click "talks" link at the top of the page and scroll down). While for me OSCON is almost over :-(, I got an early flight back to Toronto tomorrow the next two conferences are already in the works. I will be speaking at php|works Conference in Toronto around mid-September and I will be giving quite a few talks at International PHP Conference in Frankfurt in early Novembe...