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.

Jonathan takes a look at the relative popularity of Python and Ruby at Indeed.com.

Heh.

This is good news for the Ruby users out there:

“Our customers are finding Ruby on Rails to be incredibly valuable in shaping their online presence,” said Bob Parsons, GoDaddy.com CEO and Founder. “We are pleased to be able to offer support for a framework that increases the utility of the sites we host.”

Also notable is the fact that they are offering Python CGI on some of their plans as well.

Via: John Collins

There’s an interesting post at Straw Dogs about the Journey from Python to Ruby. It’s apparently the first part of a series, and it’s an interesting read. It seems that after a year of using Python, he’s making the switch to Ruby. This isn’t your typical Python vs. Ruby piece, as it has some very valid points.

Although I do think making a big issue of Python’s use of len(list) rather than list.length is a bit overdone. Guido has explained this quirk before and it’s answered in FAQ 1.4.7.

Eweek says that Ruby on Rails is poised to overtake Java as the language of choice for the web:

However, the non-Java Ruby on Rails, which is based on the Ruby dynamic language, has posed perhaps the biggest threat to Java development on the Web tier.

And perhaps the biggest Java “pressure-izer” is David Heinemeier Hansson, the creator of Ruby on Rails, who shared his thoughts on the new development landscape with eWEEK.

David does note in the article that while lots of people are using RoR in some way, it would appear that very few are using it in true production environments. But I would guess that if lots of new/younger programmers are playing with RoR in their spare time, eventually it will start showing up in a big way in IT departments as those people get hired and move up.

After a slight delay, the long awaited Basecamp API is now available. The documentation is a little on the light side, but rather straightforward. They give some examples using curl and some Ruby code to get you started. Remember that you have to explicitly enable the API for your account before it will work.

I tried some of the examples. You basically get XML responses that look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<company>
  <name>Thinkhole Labs</name>
  <city></city>
  <zip></zip>
  <phone-number-office></phone>
  <phone-number-fax></phone>
  <country>United States</country>
  <id type="integer">235827</id>
  <address-two></address>
  <can-see-private type="boolean">true</can>
  <web-address>http://thinkhole.org</web>
  <url-name>thinkhole</url>
  <address-one></address>
  <time-zone-id>Eastern Time (US &amp; Canada)</time>
  <state></state>
</company>

So the question is, who will be the first person to make a nice Python module that handles the API in its entirety? I would imagine it won’t be long before you’ll be able to put ‘import basecamp’ at the top of your script.

I think having an open API will get a lot more people to look at their product. A very good move on their part if you ask me. Of course, 37Signals does reserve the right to “modify or discontinue, temporarily or permanently, your access to the API (or any part thereof) with or without notice.”

Ah… the joy of not owning your own applications!

Update: Here’s the announcement on the SvN blog and the API forum.

Sugree put together a really interesting line by line comparison of Ruby and Python. For the example, he uses a simple XML-RPC server and client, coding in the same thing in each language.

Maybe I’ve been using Python too much lately, but to me the Python snippets just seem shorter, cleaner, and easier to read. I’m sure an experienced Ruby coder would disagree.

Looks like Ruby coders have a new place to share their weblog posts.

Quoth Straw Dogs:

A blogging and discussion corner has been set up for Ruby fanatics everywhere. You can register to begin adding your favourite Ruby blog or regularly updated Ruby content straight-away. Think Digg for Ruby.

Hrm. It looks more like the Ruby version of the Unofficial Planet Python to me… but still cool.