3 ms·

Yes, Ruby and Ruby on Rails have received a lot of flak lately, but it is well-deserved and I don't think it is "tribal" in nature. To many of us, these are ju

Yes, Ruby and Ruby on Rails have received a lot of flak lately, but it is well-deserved and I don't think it is "tribal" in nature. To many of us, these are just yet another set of tools in our very large toolbox. It's obvious that some tools are inherently better than others, however. When I point out that Ruby on Rails or JavaScript have some serious inherent problems, it's not because I think that I belong to some Python "tribe" or the Perl "camp", for instance. It's because I'm doing rational, emotionally-detached analysis of certain pieces of software, and this analysis shows there to be serious problems with said software. I think the same goes for the other people out there who have the courage to point out flaws with JavaScript, Ruby and related technologies. If anyone is acting "tribal", it's those who are so emotionally tied to a particular language or web development framework that they can't stand to hear legitimate concerns regarding important factors like security, performance, maintainability and reliability.

JshWright 14y ago
In my opinion, the first comment on the post isn't 'tribal' simply because it blindly attacks Ruby, but because it also blindly disregards the vulnerabilities in Python (which the author carefully and reasonably outlined).
- mpyne 14y ago
  Have you ever looked at the pickle docs though? There is like, literally a 'red alert' banner saying how dangerous it is in combination with arbitrary untrusted input. PyYAML's warning is not quite so blatant (http://pyyaml.org/wiki/PyYAMLDocumentation http://pyyaml.org/wiki/PyYAMLDocumentation) but when you get past installation blah blah blah onto actually loading YAML, the first thing it says (in bold) is that using .load is as dangerous as pickle.load, and it references looking as .safe_load instead. However, it would be better for the tutorial that immediately follows to use safe_load() everywhere that it can reasonably be used and to only mention .load as an advanced topic (except to mention at first that it exists but shouldn't be used)
  - Xylakant 14y ago
    You're missing the "real" vulnerability here. Yaml or in general object instantiation is the attack vector - and admittedly a particularly stupid and painful one - but the real vulnerability is sharing code via unsigned repositories. There are more vectors to break into a repository server. So the more serious problem is "How do we secure code?" and "How do we establish trust for shared code?" This issue will follow us around for quite a bit, even after the YAML bugs have been fixed and gemcutter rebuilt. For ruby that means sign gems, for python sign pip packages. And that's a point where python is not substantially better of than ruby, heck, even PHP (packagist), node (npm) and java (Maven) are in the same boat here. There's something more to learn here than pointing out that "the pickle docs are better than the psych docs" and for all the pain this incident brought the ruby developers, I'd be grateful if all other language communities learned from it - but if you rather prefer leaning back in your chair and pointing out your your communities docs state the danger clearly[1], then you're welcome. This is exactly the trap that the first commenter on the blog falls into. He sees this mess as a pure ruby problem and attacks ruby instead of stepping back and trying to figure out why this affects him as well. [1] e.g. like npm, which helpfully states that packages should be inspected before installing them. How many people do you expect to actually do that?
    - mpyne 14y ago
      You're exactly right to bring up the issues with code distribution (e.g. for CPAN, PyPI), but the YAML usage is a more general/different problem. As far as I understand it Ruby on Rails would have been vulnerable even if you installed it from cryptographically-signed tarballs without any additional code from Rubygems. But pointing out that other languages don't have super-secure code distribution systems doesn't change that they at least understand the danger of deserializers that can run arbitrary code or create arbitrary objects, especially when Ruby is also weak in this area. At least for Python I would hope that had learned their lesson in 2011 when some popular third-party Django plugins used YAML.load instead of YAML.safe_load, instead of waiting for this. Of course, RoR devs might have noticed the same issue at that time, but there's nothing we can do about it now.
      - 14y ago
byroot 14y ago
> emotionally-detached analysis of certain pieces of software Really ? Ok so please expose us your analysis if you have one instead of repeating again an again your supposed conclusion without giving us any argument.

JshWright 14y ago

In my opinion, the first comment on the post isn't 'tribal' simply because it blindly attacks Ruby, but because it also blindly disregards the vulnerabilities in Python (which the author carefully and reasonably outlined).

mpyne 14y ago
Have you ever looked at the pickle docs though? There is like, literally a 'red alert' banner saying how dangerous it is in combination with arbitrary untrusted input. PyYAML's warning is not quite so blatant (http://pyyaml.org/wiki/PyYAMLDocumentation http://pyyaml.org/wiki/PyYAMLDocumentation) but when you get past installation blah blah blah onto actually loading YAML, the first thing it says (in bold) is that using .load is as dangerous as pickle.load, and it references looking as .safe_load instead. However, it would be better for the tutorial that immediately follows to use safe_load() everywhere that it can reasonably be used and to only mention .load as an advanced topic (except to mention at first that it exists but shouldn't be used)
- Xylakant 14y ago
  You're missing the "real" vulnerability here. Yaml or in general object instantiation is the attack vector - and admittedly a particularly stupid and painful one - but the real vulnerability is sharing code via unsigned repositories. There are more vectors to break into a repository server. So the more serious problem is "How do we secure code?" and "How do we establish trust for shared code?" This issue will follow us around for quite a bit, even after the YAML bugs have been fixed and gemcutter rebuilt. For ruby that means sign gems, for python sign pip packages. And that's a point where python is not substantially better of than ruby, heck, even PHP (packagist), node (npm) and java (Maven) are in the same boat here. There's something more to learn here than pointing out that "the pickle docs are better than the psych docs" and for all the pain this incident brought the ruby developers, I'd be grateful if all other language communities learned from it - but if you rather prefer leaning back in your chair and pointing out your your communities docs state the danger clearly[1], then you're welcome. This is exactly the trap that the first commenter on the blog falls into. He sees this mess as a pure ruby problem and attacks ruby instead of stepping back and trying to figure out why this affects him as well. [1] e.g. like npm, which helpfully states that packages should be inspected before installing them. How many people do you expect to actually do that?
  - mpyne 14y ago
    You're exactly right to bring up the issues with code distribution (e.g. for CPAN, PyPI), but the YAML usage is a more general/different problem. As far as I understand it Ruby on Rails would have been vulnerable even if you installed it from cryptographically-signed tarballs without any additional code from Rubygems. But pointing out that other languages don't have super-secure code distribution systems doesn't change that they at least understand the danger of deserializers that can run arbitrary code or create arbitrary objects, especially when Ruby is also weak in this area. At least for Python I would hope that had learned their lesson in 2011 when some popular third-party Django plugins used YAML.load instead of YAML.safe_load, instead of waiting for this. Of course, RoR devs might have noticed the same issue at that time, but there's nothing we can do about it now.
    - 14y ago

byroot 14y ago

> emotionally-detached analysis of certain pieces of software Really ? Ok so please expose us your analysis if you have one instead of repeating again an again your supposed conclusion without giving us any argument.