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 s9y.org download page. Upgrade by simply uploading the deflated archive files to your webspace.

Trackbacks

Trackback-URL für diesen Eintrag

  • Keine Trackbacks

Kommentare

Ansicht der Kommentare: (Linear | Verschachtelt)

Judebert am um :

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

Simone am um :

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

Garvin am um :

Simone,

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 http://board.s9y.org/viewtopic.php?t=12402 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.

Regards, Garvin

Holger Mitterwald am um :

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 openx.org works with this. (but I doubt this might help with casts).

Michael am um :

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 am um :

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

Garvin am um :

Thanks a lot. Will contact jannis.

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

BBCode-Formatierung erlaubt
Markdown-Formatierung erlaubt