Archive for the ‘PHP’ Category.

PEL Version 0.9.1

Finally, a new version of PEL — get it before your neighbor! Pick your favorite:

The release notes follow:

Added setExif(), getExif(), and clearExif() methods as a convenient and recommended way of manipulating the Exif data in a PelJpeg object. Improved PelEntryTime to deal with timestamps in the full range from year 0 to year 9999. Removed PelTag::getDescription() because the descriptions were out of context. A new example demonstrates how to resize images while keeping the Exif data intact. Added a Japanese and updated the French and Danish translations.

That was the executive summary, there’s a bit more detail about the changes below:

  • The constructors of PelJpeg and PelTiff can now take an argument which is used for initialization. This can be a filename (equivalent to calling loadFromFile()), a PelDataWindow (equivalent to load()). The PelJpeg constructor will also accept an image resource.

  • Added PelJpeg::setExif(). This method should always be used in preference to PelJpeg::insertSection() and PelJpeg::appendSection(). One should actually not be using appendSection() unless one is very sure that the image has not been ended by a EOI marker.

  • Added PelJpeg::getExif(). This method is the new preferred way of obtaining the PelExif object from a PelJpeg object. Updated the examples and code to make use of it.

  • An example of how to resize images while keeping the Exif data intact is given in resize.php.

  • The PelTag::getDescription() method is no more. The descriptions were taken directly from the Exif specification and they were often impossible to translate in a meaningful out of context because they had references to figures and tables from said specification.

  • Fixed bug in edit-description.php which still called the constructor of PelIfd in the old pre-0.9 way.

  • Updated documentation of PelIfd to make it clearer that it can be used as an array because it implements the ArrayAccess SPL (Standard PHP Library) interface.

  • Added Japanese translation by Tadashi Jokagi.

  • Update by David Lesieur of the French translation.

  • Rewrote entry for version 0.9 in NEWS to highlight the API incompatible changes made from version 0.8.

  • Renamed test.php to run-tests.php and implemented a simple search functionality for finding the SimpleTest installation.

  • Rewrote make-release.sh script to work with Subversion.

Finally, if you insist, then go read the full ChangeLog, there’s lots of good stuff in this release :-)

WordPress insecurity

WordPress logo Another computer related thing needing attention when I got home was [WordPress][]… version 1.5.2 has just been released to fix yet another security hole, although their announcement has no specifics (as usual).

They write “We’re happy to announce that a new version of WordPress is now available for download.” How can they be happy that a security hole has been found in their “extremely stable 1.5 series” once again?! They have released version 1.5.1 (May 9th, renamed to version 1.5.1.1), 1.5.1.2 (May 27th), 1.5.1.3 (June 29th), and now 1.5.2 (August 14th) in response to security holes being found.

I think that’s a bit too much for me to call this think “extremely stable” (I obviously believe that security is an important feature of a “stable” application.) It’s good that they react to the security holes and they try to fix them fast, but I don’t like the way they just write that they have “addressed all the security issues that have been circulating the past few days”. Some questions immediately spring to mind:

  • How many security holes were there?

  • What was the nature of the hole(s)?

    • Could they “just” change the database? If so, which parts of it?

    • Could they upload files to my server? If so, could they overwrite my previous files?

  • How can I see in my log files if I’ve been exploited?

Instead of being vague I would like to see specific information about the problems. Browsing through the changesets doesn’t really help either, for the WordPress developers seems to make a point out of obscuring their fixes.

Take this changeset (revision 2779) for example, which committed on the 1.5 branch two days before the announcement of version 1.5.2 with the innocent message of “Move above”. Some lines are really moved up a little further in wp-settings.php — they deal with undoing the work of the infamous register_globals setting in PHP. But the lines are not just moved, an extra check is added to ensure that the variable $table_prefix isn’t unset. Why? Is this one of the security problems they’re talking about? Given the extreme lack of comments we can only guess…

Or maybe the fix was smugled in with revision 2780, together with fixes for seven small bugs and feature requests? The change to wp-admin/users.php in that changeset involve replacing

$id = $_GET['id'];

into

$id = (int) $_GET['id'];

and to my eyes this could be the fix they’re talking about. Especially since $id is used in an SQL query next… So if this analysis is correct then WordPress 1.5.2 was sent out to guard against an SQL injection attack. If anybody else has information about this then I would of course be interested!

Holidays — playing with PEL

Of course something would be wrong if I didn’t play with my computer now that I finally am able to do it with good conscience :-)

I’m now playing with [PEL][], I want to make an online Exif editor where you can submit your image and then change the Exif information at will. It will take some time, but I think it will be a nice demo of what PEL can do. A long the way I hope to be able to improve PEL here and there when I figure out what works and what doesn’t. The funny thing about PEL is that I have only been using it in command-line [PHP][] scripts, but never before on a webpage. So I might have missed some things when I made it — time and experience will tell.

Switching to PHP5

PHP logo I’ve just arranged to have mgeisler.net upgraded to use PHP version 5 instead of the old version 4. The site will be moved to a new server, but there shouldn’t be any downtime because of that.

I’m not sure if the new PHP5 installation will have support for the old PHP MySQL extension, and if not, [WordPress][] will stop working for a little while. It shouldn’t be long, though, for as far as I understand it, switching to the improved MySQL extension is just a matter of replacing all the mysql_*() function calls with the corresponding mysqli_*() calls.

The secret aim in this is of course to make a demo site for my little [PHP EXIF Library][pel] — I guess one would expect the author of such a library to be the first to use it, and with PHP5 on my server I’ll finally be able to do that.


A couple of hours later: Hmm… that didn’t hurt at all — mgeisler.net is now running on a server with PHP5 and so far everything seems to work just the same as before!

I must say that I’m constantly impressed by the people at NEXCESS.NET who host mgeisler.net — they have responed within the hour to every single support request, be it a small one like giving IP address SSH access, or a bigger one like going from PHP4 to PHP5. I fully agree with the praise given to Greg Swaney here: I’ve never seen better customer service.

Picking up development on PEL

Yesterday I committed some documentation updates for the [PEL][], my little pet project for reading and writing EXIF metadata using PHP.

Even though the project has been living a quiet life the last three months, people seem to download it and hopefully also use it. Please let me know (leave a comment here for example…) if you are using PEL so that I can make a link from http://pel.sf.net/ to your project.