Comment by ballard

12 years ago

That's what I like about Ruby. ;)

Even in C, Go or Python, I column align any text that is remotely similar, so differences are obvious.

Clean code might be extra work but the net work (maintenance) should amortize less. Reducing cognitive load for large supportable production codebase cannot be underscored enough.

22 comments

ballard

Reply
CCs  12 years ago

There's no "just use X" type of answer in security.

Sep 2013

"All versions of the open source Ruby on Rails Web application framework released in the past six years have a critical vulnerability that an attacker could exploit to execute arbitrary code, steal information from databases and crash servers."

https://groups.google.com/forum/#!topic/rubyonrails-security...

Nov 2013

"A lingering security issue in Ruby on Rails..."

http://threatpost.com/ruby-on-rails-cookiestore-vulnerabilit...

Dec 2013

"Ruby on Rails security updates patch XSS, DoS vulnerabilities"

http://www.infoworld.com/d/security/ruby-rails-security-upda...

  • Xylakant  12 years ago

    Ruby != Rails. We do a lot of ruby, but practically no rails.

    • CCs  12 years ago

      C != OpenSSL. Some [1] would argue OpenSSL is not representative at all what C can do. Maybe you should check out Redis for beauty [2] and joy [3].

      On the same note C != C++ either and you can write large systems in C++ without ever using memory allocation. You can use only bounds checked functions.

      And you can have large security holes if you're not careful, no matter which language you pick.

      [1] http://news.ycombinator.com/item?id=2275413

  • lmm  12 years ago

    Rails does plenty of "make life easier for the programmer" things that I would expect to increase the risk of security issues. Do you have those kind of problems for e.g. Haskell?

    • dtech  12 years ago

      Haskell problably has/would have the same kind of problems, but finding examples will be a lot harder in the absence of large well-used web platform à la RoR

      3 replies →

    • rickr  12 years ago

      Remember - Rails is a framework for webapps. Haskell is a language. You should be comparing ruby to haskell.

  • khafra  12 years ago

    Write everything in Coq.

    • tel  12 years ago

      Perhaps more reasonably: write the core of your application in Coq and have it expose a DSL for writing business logic atop this infallible core.

funkiestj  12 years ago

you get it but the opinion of "C and C++ are fine for SSL, the OpenSSL guys just screwed up" is plain wrong.

This is a question of priorities. We have speed and security. If you chose C/C++ (non-existent automated checking of memory access) you are chosing speed first, security second.

If security is critical then you need to chose a language that makes array out of bounds access well nigh impossible. This is an easy problem -- we have languages that will give this to us.

What percentage of exploits in the wild come from array (and pointer) access out of bounds? I'd venture to say it is above 50%.

Rather than have programmers everywhere "try hard to be careful" writing this code, let them use a safer language and have a few really smart folk work on optimizing the compiler for said language to make the safety checks faster (e.g. removing provably unnecessary/redundant checks).

People think that chosing C/C++ has a better business case (i.e. better performance / scaling) because "being really careful" works most of the time. The problem is when heartbleed (or the next array out of bounds access bug) hits the the business case's ROI no longer looks so much better than the safer path.

A better language won't eliminate all security holes but it can eliminate a huge class of them and allow engineers to focus the energy they used to spend on "being really careful about array access and pointers" on other tasks (be they security, performance or feature related).

EDIT: stating the obvious .. there are good uses for C style languages but writing large bodies of software that needs to be resistant to malicious user attacks is not one of them.