Just a quick proof of concept post from the Palm Tungsten C I picked up on Ebay. Seems to work pretty well so far…

JP explains why he chose Python over Ruby, including a discussion WSGI and of web frameworks.

Now that my transition from SusCom to Comcast is complete, I checked my bandwidth again tonight:

Not bad.

Quoth Kevin Dangoor (of TurboGears):

I guess I’d better give up now. Guido announced at SciPy that Django is the “standard” web framework for Python. How’s that for a first two sentences of a blog post? Of course, only one of those two sentences is accurate.

Read the whole thing.

Back in April I mentioned using Mutagen to read/write ID3 tags. Someone recently left a comment suggesting eyeD3 which is, according to the project site, a “Python module and program for processing ID3 tags.”

I haven’t personally looked into it, but if you are interested in cleaning up your MP3s using Python, eyeD3 might be worth checking out.

Last Thursday (talking about Rails) I said:

The time will come when each of the other frameworks will be found to have critical security flaws as well.

The only question is… how will they handle it when it happens?

Well, it happened sooner than I thought. Tonight Andrian announced on the Django weblog that a “small security hole” has been fixed in Django’s translation helper utility.

Quoth Adrian:

The Django team discovered and fixed a small security hole in the django/bin/compile-messages.py helper script, which is the script that compiles language translation message files (.po files) into binary format (.mo files).

The compile-messages.py script uses the name of the .po file to build arguments to a system command, and it didn’t sufficiently validate the filename for potentially malicious content.

According to the post, “No exploit based on this vulnerability, proof-of-concept or otherwise, is known to have existed.”

The security notice appears to be full disclosure, with a rather detailed explanation of exactly what the problem was and how it has been fixed. I’m assuming time from discovery to fix was short, but that’s not specifically mentioned.

All things considered, it looks like they handled this one pretty well.

Comment spam used to be nothing more than a tiny annoyance, but as this site’s traffic has increased so has the amount of spam. Currently it all goes into a moderation queue until I approve/delete it. It’s not a huge burden to check the queue once in a while and process the comments, but I figured there had to be a better way.

Based on a suggestion from Lon, I installed Akismet tonight.

Akismet (free API key required) uses a collaborative web service to decide if each comment is spam or not. If it gets tagged as (potential) spam, it goes into a special queue that is automatically deleted after 15 days. So, assuming I don’t get a lot of false positives, I should be set.

We’ll see how it goes, but so far so good.

This news is from the other day, but I somehow missed it until just now…

Quoth Jason:

Rails turns 2 and Apple sends over a little birthday gift: Ruby on Rails will be included with Leopard (both server and client). It’s been quite an amazing ride for a little web application framework we extracted from Basecamp (Basecamp was the first Rails app and the reason Rails exists today).

More at the Rails blog.

David finally admits that the cat is out of the bag and gives full disclosure on the critical security hole in Ruby on Rails:

With Rails 1.1.0 through 1.1.5 (minus the short-lived 1.1.3), you can trigger the evaluation of Ruby code through the URL because of a bug in the routing code of Rails. This means that you can essentially take down a Rails process by starting something like /script/profiler, as the code will run for a long time and that process will be hung while it happens. Other URLs can even cause data loss.

It’s good that the RoR team has released the details of the problem and are working hard on all security aspects of the framework. They’ve even started a new mailing list for dealing with security issues. That’s a Good Thing.

But still, I’m left wondering why David decided to handle this the way he did. This exercise in security-by-obscurity certainly wouldn’t have prevented a determined person from finding the diff in the code and exploiting it. And yet it made it very difficult for admins with sites running RoR to make informed decisions on how to handle the news.

I just don’t understand, and I’m apparently not the only one…

Quoth Evan Weaver:

Core team discovered a security vulnerability in recently released 1.1.4., and then came to the conclusion, same as I did, that 1.0 and some intermediate 1.1 releases are not affected. They have provided a patch, but no explanations, which is beyond frustrating to those who have to decide whether its better to risk breaking their application by applying this mysterious patch, or continue running with a vulnerability of unknown severity.

Indeed.

The time will come when each of the other frameworks will be found to have critical security flaws as well.

The only question is… how will they handle it when it happens?

Quoth the Ruby on Rails blog:

This is a MANDATORY upgrade for anyone not running on a very recent edge (which isn’t affected by this). If you have a public Rails site, you MUST upgrade to Rails 1.1.5. The security issue is severe and you do not want to be caught unpatched.

The issue is in fact of such a criticality that we’re not going to dig into the specifics. No need to arm would-be assalients.

Nate took a look at the code and ran a quick diff on it, but he says he looks like they may have renamed a few files. Interesting.

According to the devs, the problem affects 0.13, 0.14, 1.0, and 1.1.x.

So, what exactly is the problem? Is it an SQL injection hole, or are the RoR developers are just adding red herrings?

Either way, this isn’t looking good for the RoR team. Not because there is a security flaw, but rather because of how it’s being handled. I’m not the only one expecting some backlash over this.

Oh well, as David Heinemeier Hansson himself has said:

There’s no need to fear. Security is not likely to ever be a bullet point on the feature list of a framework. All Rails does is provide you with a number of features to _help_ deal with security, like SQL injection…

Heh.

Update: Kristian Köhntopp looked into the Mandatory Mystery Patch and appears to have found a flaw by running a diff on 1.1.4 vs. 1.1.5.