Hacker News Reader

Comment by static_typed | Hacker News Reader

Given we are still seeing more security issues with Rails, shouldn't the developers down tools for 5 mins to stop with the shiny-shiny, and maybe rewalk the codebase, the dependencies they set, and review things?

Yes, they are quick to band-aid the overall problem, and push out yet another version bump, but, no one other there seems to really grasp the nettle and admit too much auto, too much magic, too much opinionated design has meant a framework with more holes than swiss cheese. We have only just started to see the trickle of reported issues, before the flood.

Ironically, we had a call this morning from a customer that there rails app server has been compromised, despite diligently patching and updating.

I would rather see one better update to Rails for the release versions, arising from a proper audit, proactively closing the windows left from before, rather than shutting one each time it is reported.

View on HN

> Given we are still seeing more security issues with Rails, shouldn't the developers down tools for 5 mins to stop with the shiny-shiny, and maybe rewalk the codebase, the dependencies they set, and review things?

This is what's been happening and why we have seen a ton of releases.

+1. Exactly. This is why so many of these bugs are coming up now. It is a very good thing.

Actually, the 'shiney' new versions don't have this bug. Only rails < 3.1

I would argue that opinionated design and to a certain extent "magic" on the whole can reduce the amount of security problems.

Compare something like rails with sites that are developed in vanilla PHP. In my experience it is rare to find a vanilla PHP site that doesn't have a whole menu of vulnerabilities which can be found within ~10 minutes of prodding. Granted this might mean that each site has different vulnerabilities that have to be found on an individual basis rather than some vulnerability that can be attacked by spray and pray tools.

Rails will give you some very sensible defaults that even inexperienced developers get benefit from, just having template HTML sanitised, CSRF tokens and parametrised queries by default stumps a whole load of attacks that you would otherwise have to consider every time you build each web page.

> I would rather see one better update to Rails for the release versions, arising from a proper audit, proactively closing the windows left from before, rather than shutting one each time it is reported.

Really? You'd rather security patches not occur and instead be issued via large batch releases? If that's truly the case, you could achieve the same end by not patching and upgrading to the next major version release. However, that seems truly more dangerous than the inconvenience of incremental patching.

lol.

What version of their Rails app was compromised?

Reply on news.ycombinator.com