Serendipity 1.3.1 released

Serendipity 1.3.1 has been released. This is a bugfix and security related release, basically adressing a potential XSS issue within the Top Referrers plugin as well as hypothetical XSS issues with the installer.

This release also adresses some basic PostgreSQL8 related problems, because implicit type casts have been removed from this version, causing breakage with several Serendipity core features. The fix for this is only partial and will still happen in (less common) functions of Serendipity. There is no ultimate solution to this because implicit type casts are required for certain entryproperty operations. Maybe the PostgreSQL8 team will think about if implicit type casts are not also quite helpful. ;-)

The only new feature addition is the exposition of a new smarty {serendipity_getImageSize} function.

This upgrade is recommended for users that use the Top Referrers plugin and new installations of Serendipity. Many thanks to Hanno Böck, once again, for reporting (and fixing) the two XSS issues (CVE-2008-1385 and CVE-2008-1386)!

You can find the new release on the download page. Upgrade by simply uploading the deflated archive files to your webspace.


Trackback specific URI for this entry

  • No Trackbacks


Display comments as (Linear | Threaded)

Judebert on at :

This release also includes updates to the Karma plugin, allowing karma bars to be displayed on summary pages.

Simone on at :

I fail to see how "there is no ultimate solution to" PostgreSQL problems: simply use explict casts where needed.

Garvin on at :


thanks for discussing this. We are actually in need of people who use pgsql and s9y and can help in finding a solution.

Additionally to what is stated in here's a quick summary: Serendipity uses a single SQL code that runs on all DBs we support (MySQL,SQLite,PGSql,SQRelay). There are only few exceptions to that SQL, namely where DISTINCT vs. GROUP is used, which requires special case for PostgreSQL.

As for implicit casts, we use those in a central place of the code, where basically any involved DB table can contain a column that is matched against a user specified term. At that point in code, plugins can interfer and supply custom joined tables with differing column types, but all need to be generally matched against the key.

So for this, onle the "LIKE" command or "=" term with single quotes (implicit string cast) really works, because at that place in code, the script might not know if it needs to match an integer or a string. To change this would mean that every plugin or code that hooks into those central functions first needs to check which column type a match key is. That would mean additional performance hits as well as changing all plugins that relate to this. This is nearly an impossible task and involves tidious patching of a lot of plugins.

However, this really is a thing where implicit string typecasting makes sense, and I actually fail to see why this is removed in PGSQL, BC-breaking a lot of existing code (not only s9y).

Typecasting should not simply be put up to the application; IMHO it's the job of a database to do actual casting on its own, introspecting the input and other meta information that is. It's just like lazy variable initializing in PHP: You can simply prototype faster if you are not restricted to explicit casting.

Hope that clears up some things and why I see that more of a shortcoming of PGSQL design decisions.


Holger Mitterwald on at :

It is more a philosophic question which part of the software should do automatic casting. Fact is, postgresql doesn't do it any more and breaks s9y.

Perhaps I might help getting s9y running on pgsql - simply as I want to use both of them in future.

Question is if you should build a small Framework with object-oriented methods. So you can declare most of the SQL-Statements for all databases. Those who differ are overwritten in a database-specific include. So you have to explicitly load a database-specific driver for your database. I really can't imagine a good/fast solution otherwise.

On the other hand there are some lets call it "mysql-Emulation" funktions available for pgsql. As far as I know works with this. (but I doubt this might help with casts).

Michael on at :

This seems to be a release with lots of helpful options. As I've been to busy to notices this new release I will catch up on this now.

AO on at :

Garvin - the TLD / forum seems to be down / unavailable.

Garvin on at :

Thanks a lot. Will contact jannis.

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.

BBCode format allowed