Escape Velocity (opens in new tab)

Same here. Was an extremely funny space trade / exploration / shooting game. PC users missed out on this great piece of classic Mac shareware.

Small "let's play" video: https://www.youtube.com/watch?v=4VX6TZEfqf4

Came here hoping it was this. Ah well, there's always Transcendence: http://transcendence.kronosaur.com/

Man I wish. Enough talk about Monkey Island. Escape Velocity was a fantastic adventure game that could use some more sequels.

Clearly we all (myself included) have one-track minds.

Me too, me too. So disappointed.

The article should have pointed out that Github is running Rails 2.3, and that this is where the problem exists.

Rails 3.x has reworked the entire escaping situation and now avoids the re-escaping trap (strings must be flagged as "HTML safe", otherwise they are escaped on final injection into a document). It still has escape_once, but it's not used by Rails itself.

You are of course right to blame 2.x for its flaws, but let's not blame entire projects for problems that have been fixed. (Not that Rails 3.x does not have other egregious inefficiencies, but that's another story.)

Why is it a problem?

My guess is that it has something to do with the fact that Github is made up almost entirely of user generated content. Just load a Github project page. From top to bottom, you have:

    * Username in the header (which is probably validated with a specific format,
      so probably doesn't need escaping).
    * Project summary entered when the project is created.
    * Drop-down with list of branch and tag names.
    * Latest commit message.
    * List of names for all folders and files tracked in git for the project.
    * Readme text.

That's just the homepage for a project, and each one of those things could potentially contain malicious HTML or JS, meaning it should be escaped before rendered on the page.

The problem occurs with templates such as in this (HAML example):

    - posts.each do |post|
      %li
         = link_to post.title, post_url(post), class: "post_link"

Note that in the case of Rails 2.3 (which the article describes), Rails doesn't know if post.title, post_url() or "post_link" have been escaped or not. It originates at a time when the Rails people were fairly lax and ignorant about encodings and sanitization in general.

For the post.title bit, the link_to method just passes it along, assuming it's valid HTML. Which means it's an injection point if the post was user-submitted. The URL and the {class: "post_link"} are passed through escape_once, described in the article.

As you can see, the amount of data that must potentially be sanitized/encoded can be a lot; lots of small pieces of text that add up to a lot of overhead.

Rails 3.x fixes this by assuming that no strings contain sanitized HTML; therefore, when you insert data into a template, it will automatically escape everything. This is good. If you know that something is already sanitized, you can declare it as such:

     = link_to post.title.html_safe

This flags the string as safe, and link_to will not need to escape it.

`phillmv has identified the biggest concern for sure, but more broadly speaking, you have issues whenever you cross one of two boundaries: 1) escaping context [characters get escaped differently in URLs, JavaScript, HTML, etc.] and 2) user-defined content.

The latter is the source of XSS attacks, but the former is a pain too. Let's say that you run a stock photo website, and your database has images and captions. You decide you want to use captions for the alt attribute of your images, and one of your captions is Cat saying "meow!". If you blindly insert that caption into your HTML without escaping, you could end up with

  <img src="cat.jpg" alt="Cat saying "meow!"">

And now you've got crappy HTML on your hands. It's the same principle as XSS attacks, but you do it to yourself with less disastrous (but still unwanted) effects.

EDIT: Hm, seems like the comment I referenced is now gone? `phillmv pointed out that cross-site scripting (XSS) is an important reason to use escaping appropriately (and often widely).

So, what's their upgrade path situation? Are they going to try to hold out indefinitely on 2.3? Upgrade at the last possible moment? (Ick) Switch out of Rails when the situation becomes intolerable?

Seems kinda par for the course for a Rails app.

http://meta.discourse.org/t/tuning-ruby-and-rails-for-discou...

Scroll down and you'll see that on an average request, Discourse eats up 230,000 strings [which are all objects in Ruby] per request.

The entire thread is about relaxing the garbage collector so that it won't run until the request is over.