Security

In January 2013, two upgrades to Rails were required in quick succession, in response to security problems that would have let anyone take control of any running Rails app.

Here are some notes on security issues, how we handle them, etc.

Upgrades to Rails
First, of course, determine if it affects us. Generally better to be safe than sorry.

Someone needs to upgrade Growstuff itself: in the case of a new patch release to Rails itself, this is a matter of editing the Gemfile then, make sure all tests pass, etc. It's possible to wind up in dependency hell with this (as we did with 3.2.8). Generally, specifying desired versions of things in the Gemfile will prevent this more than not specifying them.

Commit, pull request, merge, deploy, etc. If it's just a Gemfile update, Travis passes the tests, and there's nobody around to cross-check your work, this is one situation where "just merge it" is probably in order.

At the same time all this is going on, we need to take steps to secure our developers' dev boxes. In the case of the recent Rails problems, any running Rails app -- including those on localhost:3000 on dev's machines -- could be at risk. (For instance, via a web-based scripting attack that points at localhost:3000.)

We should email our devs and tell them to kill any running rails instance, then  before running it again.

Meanwhile, there may be running instances on the hack server. Someone needs to go there and  any "rails s" processes. These aren't on port 3000 but still, if not stopped they will be found by someone nasty.

Query: is there any way to prevent hack server users from subsequently running an unpatched Rails, for instance if they login and do  before  ?