The biggest issue we have seen in client projects, where they have an existing Rails project is not just the numerous holes in the core framework, but that they used many, many gems, the majority of which end us as abandonware, and are often chock-full of poor code, security blunders and generally bad design, that leaves the site wide open.
We have been able to successfully migrate a number of clients onto alternative lighter frameworks, or in some cases lean stacks, given they received a massively over engineered rails project for what was really a CMS requirement.
I really hope one day to stumble onto a well written, well maintained and we'll designed Rails app, but have not seen one yet...
Perhaps that's because the kind of person who has this kind of attitude, and who'd create an account called "tddfuckwitz" to come and spout it on HN, doesn't make a very good impression on the kind of rails devs who do know what they're doing, so you don't win them as clients.
- signed, a professional rails dev who takes security and code quality very seriously indeed
Cute - inserting the word 'professional' before rails dev, and then claiming to take security and code quality seriously!
ROFL
If a developer was professional, and cared about code quality and security, they would not use rails. Period.
Yeah! They'd use PHP! Or Java! Those never have any problems and their code-bases are always flawless.
I'll take a bad Rails app any day over what people churn out in other platforms. I've seen Java apps so impenetrably opaque it's not even clear what it does. Rails is Rails. It's boring. It works. It's pretty hard to mangle the project so badly that you can't make sense of it.
Unless, of course, you've got no idea what Rails is or how it works.
Laravel has tried to push PHP in the right direction in a huge way, but it's not without its minor problems, either. Additionally, like any non-trivial code base it's had some vulnerabilities.
Now of course nobody uses Laravel, they just hand-roll, so the sorts of bugs you see in the PHP world are more pattern based (e.g. injection, XSS) than you'd see in a platform like Rails that is driven by convention.
It's imporant to pick out vulnerabilities and deficiencies compared to other projects to get them addressed, rather than only say nice things. However, the core issue is that people raising them are usually ignored until there's an embarrassing hack or demonstration (Homakov).
For example, all new gem releases should be signed and `HighSecurity` should be the policy but it's taken years to get very little progress. Changing to that policy would prevent entire classes of attacks, attacks that could subtly inject code into all sorts of apps in difficult-to-find ways. Large projects are still shipping unsigned gems, unsigned commits and unsigned tags. If RubyGems were hacked, progress might move slightly faster.
Rubygems has been lagging behind other packagers like Apt, RPM, NPM, and even newer things like Rust's Cargo. It's woefully overdue for an update.
That being said, there's great services like GemCanary (https://gemcanary.com/) that will read your Gemfile and produce a list of vulnerable packages for you automatically. It'll even email you alerts when there's problems.
The security story in Rails might not be perfect, but at least there's reporting and tools.
Keep pushing for signed packages, though. Long overdue.
You're getting downvoted because security issues are far from unique to Ruby on Rails. Are you aware of any web frameworks with a pristine security history?
The problem with thinking this way is that you don't know what security issues that nobody knows about yet are lurking in there. I remember the time before the recent spate of Rails vulnerabilities in the last 5 years or so, and I thought similarly about its security as you seem to about the Nodejs ecosystem. It's definitely possible that your confidence won't ever be punctured by a similar run of security issues, but my personal view is that it tends to be hubris to think your favorite technology is just better at security, for vague reasons.
26 comments
[ 5.9 ms ] story [ 134 ms ] threadWe have been able to successfully migrate a number of clients onto alternative lighter frameworks, or in some cases lean stacks, given they received a massively over engineered rails project for what was really a CMS requirement.
I really hope one day to stumble onto a well written, well maintained and we'll designed Rails app, but have not seen one yet...
Perhaps that's because the kind of person who has this kind of attitude, and who'd create an account called "tddfuckwitz" to come and spout it on HN, doesn't make a very good impression on the kind of rails devs who do know what they're doing, so you don't win them as clients.
- signed, a professional rails dev who takes security and code quality very seriously indeed
I'll take a bad Rails app any day over what people churn out in other platforms. I've seen Java apps so impenetrably opaque it's not even clear what it does. Rails is Rails. It's boring. It works. It's pretty hard to mangle the project so badly that you can't make sense of it.
Unless, of course, you've got no idea what Rails is or how it works.
Laravel has tried to push PHP in the right direction in a huge way, but it's not without its minor problems, either. Additionally, like any non-trivial code base it's had some vulnerabilities.
Now of course nobody uses Laravel, they just hand-roll, so the sorts of bugs you see in the PHP world are more pattern based (e.g. injection, XSS) than you'd see in a platform like Rails that is driven by convention.
- http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-...
- http://www.cvedetails.com/vulnerability-list/vendor_id-12043...
Picking on it for having vulnerabilities without providing something in the way of a comparison is not very meaningful.
For example, all new gem releases should be signed and `HighSecurity` should be the policy but it's taken years to get very little progress. Changing to that policy would prevent entire classes of attacks, attacks that could subtly inject code into all sorts of apps in difficult-to-find ways. Large projects are still shipping unsigned gems, unsigned commits and unsigned tags. If RubyGems were hacked, progress might move slightly faster.
That being said, there's great services like GemCanary (https://gemcanary.com/) that will read your Gemfile and produce a list of vulnerable packages for you automatically. It'll even email you alerts when there's problems.
The security story in Rails might not be perfect, but at least there's reporting and tools.
Keep pushing for signed packages, though. Long overdue.
Django: http://www.cvedetails.com/product/18211/Djangoproject-Django...
PHP: http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id...
JRE: http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend...
.Net: http://www.cvedetails.com/product/2002/Microsoft-.net-Framew...
http://expressjs.com/advanced/security-updates.html
Yeah I think I'm going to take my chances with Express.js rather than Ruby on Rails with it 57 vulnerabilities in 6 years.