It's an often told story that the free software community cares more about security. That it's much better because everyone can look at the code. While this may sometimes be true and I know many free software projects really care about security issues, often enough it's the exact opposite.

On 26.04., some guy called Marsu released an advisory about the GIMP. Loading files in the sunras-format can lead to a buffer overflow. Now, while it was silently fixed in svn, for a month they didn't put an advisory on their page and they didn't provide an update. Even with the release of new versions (2.2.15, 2.3.17), they somehow »forgot« to mention that it was a security-update.
Now, after looking into the NEWS-file (which is their Changelog), for 2.2.15 there's this little line:
- guard against a possible stack overflow in the Sunras loader (bug #433902)
They didn't mention the word »security«, they didn't give credits to Marsu, they didn't provide a reference to the advisory or the CVE-ID. Now, even worse, for 2.3.17, they forgot to mention that bug at all (it's probably part of the mentioned »lots of bug fixes«).

Now one might say this isn't that critical, because who uses sunras (I also never heared of that format before)? But think about this: I could mail someone a crafted sunras-file, saying it's an old image I found on some backup HD, together with the note that gimp can open it. I think it's not unlikely that someone might open it, especially with some intelligent social engineering. Beside that, EVERY SINGLE security bug should be taken serious.

Now, don't take me wrong. I love the GIMP, it's a great application. I also think that free software is an important precondition for secure software. But it's not the only thing. And as long as many people in the free software community treat security bugs like this, it's no better than those in the proprietary world.

In wenigen Stunden geht's los zur webinale open in Ludwigsburg. Dort werden wir als Linux User Group Backnang präsent sein, ebenso wird schokokeks.org sich präsentieren.

Am LUG-Stand werden wir verschiedene Projekte, unter anderem OpenStreetMap und CAcert, vorstellen, sowie Kubuntu-CDs verteilen und Compiz zeigen.

Erste Bilder

Up until recently, I had URLs of the form /item/number, which is due to the reason that this was the URL-naming-scheme of bblog, an ancient blogging software I used years back. Now serendipity supports URLs with the title (minus problematic charakters), which is much better for search engines, because they often rate words that appear in the url better. Now, changing the URL after years of blogging doesn't seem appropriate (probably hundreds of links, trackbacks, bookmarks), so I needed some migration path. Serendipity doesn't support two url schemes out of the box, so I hacked some bash to do the trick. This will generate (after changing the url) forward rules (add them to .htaccess after the s9y-stuff), which send a »moved permanently«-answer. This has do be done only once, as there won't be links on new articles with the old scheme.
It's a fast hack and it probably doesn't fit in other situations without changes, but it's a nice example how fast you get somewhere with some bash and sed magic:

for i in `seq 1 31`; do

        wget --quiet -O - http://www.hboeck.de/archives/P$i.html|grep serendipity_title | \

        sed -e 's:^.*href="\([^"]*\)">.*$:\1:g' | \

        sed -e 's:^/\w*/\(\w*\)-.*:RewriteRule ^item/\1 \0 [L,R=301]:g'

done