Development

The Internet Explorer 9 has been released a few days ago. It's a great improvement over old versions, despite of one mayor breakage.

Usually, a web-browser requests a CSS URL with a variety of HTTP-headers. The "Accept" HTTP-Header instructs the remote server, which valid content-types it can handle. In the past, most web-browsers sent a "Accept: text/css; */*" header, which means they prefer "text/css", but would also interpret any other file types as CSS.

Now, the IE9 does no longer send */* as an accepted content-Type, thus it will now ONLY render stylesheets if they have the Content-Type "text/css". If that does not happen, IE9 complains with a "HTTP 406" error and refuses to parse/render the stylesheet.

That does not sound so bad yet, but many web-applications (including Serendipity) provide dynamic CSS stylesheets that hide behind a PHP file. Serendipity compiles this PHP through a file called "serendipity.css.php". If URL rewriting is enabled, to mask that PHP file, a RewriteRule is added that will accept "serendipity.css" and send it to the main serendipity index.php file, which in turn will include serendipity.css.php and deliver the appropriate output.

Now certain Apache setups use a module mod_negotiation that will detect "Hey- there's a file serendipity.css.php, but the browser requested serendipity.css. He surely must be mistaken, I better serve up this serendipity.css.php file instead". Sadly, it does so, BEFORE executung mod_rewrite that would "fix" this behaviour.

Finally - mod_negotiate would basically properly execute the PHP file and return valid CSS. But it does that by returning a Content-Type that matches the original negotiated request, which is "application/x-httpd-php". IE9 will receive this, and refuse to render the proper CSS, because it does not accept */*.

IMHO this is a very bad mixture of several components acting weird altogether. But the easiest place to fix this is inside IE9, to restore the "Accept" behaviour of all other major browsers, so that mod_negotiated sites will not break.

I have posted on a IE9 Team blog since it seems, Microsoft does not accept bug reports anywhere. If anybody knows of a proper place to get a hold of their team, please let us know.

FINALLY - WHAT YOU CAN DO IF THIS AFFECTS YOUR SERENDIPITY BLOG:

Edit your .htaccess file, and add the directive Options -Multiviews at the top of the file. As long as your server has the AllowOveride ability enabled for you (that's mostly the case, as soon as you are allowed to use mod_rewrite) you can remove the negotiation feature of Apache.

This change in the default .htaccess will also be part of upcoming Serendipity versions.

Clarification: This is not only IE9's fault, but rather a bad combination of multiple factors: One being that s9y has a .php file called the same way like a rewritten URL. One being that mod_negotiate does not pass a request through to mod_rewrite and fatally catches it before other means are not used up. And the last being that IE9 does not accept a fallback contenttype for CSS.

The reason why I think this should be considered a IE9 bug, is because the restrictive parsing stats against current plans to make the web as accessible as possible. XHTML actually failed in its restrictive, XML-based parsing (google mime-type application/x-html+xml) was stomped down in favor of a lax HTML5 parsing. Users should never be locked out of content, and that's why I think a fallback */* should not hurt. This allows for applications to overcome mod_negotiate and allows the browser to evaluate the final Content-Type, and not an intermediate negotiated one.

Onli has contributed a new plugin to spartacus, called serendipity_event_autoupdate. It is currently very much in experimental state and is meant to aid in the process of upgrading Serendipity (which already is quite easy, but automatic might even be better, right?).

If you are interested in this feature, now is the time to help develop it! Please give Feedback to online (german) or directly on the corresponding forum thread.

Serendipity bundles the powerful Xinha WYSIWYG editor to provide its functionality to our users.

Xinha ships with several plugins that utilize PHP scripting for special usage, like the ImageManager or ExtendedFileManager. A 0-day security exploit has been reported available as of today that exploits the functionality of these plugins to upload malicious files to your webspace, to execute foreign code.

Since no official patch has been made on the Xinha side, the Serendipity Team has released an updated version where those active Xinha-Plugins are no longer executable.

If you do not wish to apply the patch to the most recent Serendipity version 1.5.5 you can remove those files:

• htmlarea/contrib/php-xinha.php
• htmlarea/plugins/ExtendedFileManager/config.inc.php
• htmlarea/plugins/FormOperations/formmail.php
• htmlarea/plugins/HtmlTidy/html-tidy-logic.php
• htmlarea/plugins/ImageManager/config.inc.php
• htmlarea/plugins/InsertPicture/InsertPicture.php
• htmlarea/plugins/InsertSnippet/snippets.php
• htmlarea/plugins/SpellChecker/aspell_setup.php
• htmlarea/plugins/SpellChecker/spell-check-logic.php
• htmlarea/plugins/SuperClean/tidy.php

The provided functionality is usually not enabled by default, since Serendipity provides its own media file manager.

Future serendipity releases might re-enable these features, once they are safely patched.

To see if you are infected, please check the directories htmlarea/plugins/ImageManager/demo_images and htmlarea/plugins/ExtendedFileManager/demo_images to see if files have been uploaded there. If so, delete the files and check your webspace for other modified files, as well as change your passwords for FTP and SQL access. Please upgrade as soon as possible.

The release can be found on the Serendipity Download page. All serendipity versions from 1.4 to 1.6 (alpha) are affected. 1.6 alpha users should migrate to a recent SVN head checkout or tomorrow's snapshot.

Thanks a lot to Hauser & Wenz for reporting the issue. Serendipity fully acknowledges responsible full disclosure, non-reported 0-day exploits are helping nobody of true OpenSource spirit.

As we were notified on our forums, the updated PHP 5.3.2 version seems to have changed a behaviour of quoting array variables within strings, which produces a PHP parse error on a serendipity file include/functions_entries.inc.php at line 1433 (in Serendipity 1.5.3).

The fix is actually quite easy, if you replace the code found at line 1433 from this:

serendipity_db_query("DELETE FROM {$serendipity["dbPrefix"]}entries WHERE id=$id");
serendipity_db_query("DELETE FROM {$serendipity["dbPrefix"]}entrycat WHERE entryid=$id");
serendipity_db_query("DELETE FROM {$serendipity["dbPrefix"]}entryproperties WHERE entryid=$id");
serendipity_db_query("DELETE FROM {$serendipity["dbPrefix2]}comments WHERE entry_id=$id");

to this:

serendipity_db_query("DELETE FROM {$serendipity['dbPrefix']}entries WHERE id=$id");
serendipity_db_query("DELETE FROM {$serendipity['dbPrefix']}entrycat WHERE entryid=$id");
serendipity_db_query("DELETE FROM {$serendipity['dbPrefix']}entryproperties WHERE entryid=$id");
serendipity_db_query("DELETE FROM {$serendipity['dbPrefix']}comments WHERE entry_id=$id");

If you can't easily spot the difference: It's changing ["dbprefix"] with double quotes to ['dbprefix'] with single quotes. We're sorry for this inconvenience, which is already fixed in our SVN branches and will be part of the next release.

Thanks a lot to fyremoon from the forums, this thread.

Serendipity 1.5.2 has been released to address the outstanding issue of SQLite installations with Serendipity. Upgrading an earlier version of Serendipity prior to 1.5.1 to this version should work without any problems, fixing the database upgrades that were faulty in Serendipity 1.5.1. This is the same patch that has been advertised in the old blog posting.

Users who had upgraded to Serendipity 1.5 already can fix problems by checking the database table 'serendipity' and make sure to insert a md5 hashed password, with hashtype=0.

SQLite users should backup their database file (a random file name ending in .db) before updating. For users of other database systems, the Serendipity 1.5.2 update does not contain any changes and can be left out.

UPDATE: Serendipity 1.5.2 release

Some SQLite upgrades from Serendipity prior to 1.5 to the current version might create a problem, that the database update cannot properly update the serendipity_authors database table structure to insert the new "hashtype" (int) column. Due to that column missing, this can lead to the inability to log in.

Sadly SQLite does not easily allow to ALTER a table structure, so unless you have a SQLite admin tool to manually that column, and until the Serendipity Team can provide a proper fix, you should not yet update. Due to Christmas 2009.1 getting released soon, this might takes us a few more extra days.

If you have NOT yet uploaded the new serendipity release and executed the update, you can simply copy the file sql/db_update_1.5-alpha1_1.5-alpha2_sqlite.sql onto your installation, which fixes the upgrade procedure.

Side information: Hashtype defines whether md5 (value '0') or salted sha1 (value '1') is used for the stored encrypted password of the serendipity_authors table. Once you login with a hashtype=0, serendipity will automatically convert your password to sha1, and adjust the hashtype column. This is why once we fix this issue in 1.5.2, we must make sure that no manuall updates you might have used are overwritten, that could lead to Serendipity no longer knowing which hashtype was used for your column. That requires some thoughtful thinking, and a bit more time instead of a hotfix that might make the situation worse.

Note that this ONLY applies to users UPGRADING and using SQLite. A fresh installation as well as using other Database types is not affected.