7 ms·

The call to action in this post is not strong enough - RubyGems and RubyGems.org are completely volunteer-run, open source projects. If you want to fix these pr

by qrush 14y ago

The call to action in this post is not strong enough - RubyGems and RubyGems.org are completely volunteer-run, open source projects. If you want to fix these problems, please get involved and stick around.

PommeDeTerre 14y ago
Another approach is to completely move away from using Ruby, Ruby on Rails and related software. I think that the recent security issues are evidence of many systemic problems within the Ruby community, and with their approach and attitude toward software development. Security should be inherent and considered from the very start, rather than brought on over time by an endless stream of patches and updates. Furthermore, the focus should not be on cranking out libraries and code as quickly as possible, especially when said code is rife with security holes. There are many other programming languages, libraries and communities that take a far more sensible approach to software development. We see far fewer of these kinds of issues arise when things are not done the "Ruby" way.
- phillc 14y ago
  Your philosophies are sound for banking software. There are cases where startups, social impact organizations, or any fast moving team would pick rails for its fast movement, accessibility, and support, even if they thought that there were even more security issues than that have happened.
  - PommeDeTerre 14y ago
    That's a very dangerous attitude to have. Security is not something that should be traded off just to reduce development time or effort slightly. Regardless of the situation, it's much more responsible to focus on doing security properly, while cutting corners on the UI, documentation or other less-critical areas of the application. Those are generally the kind of updates that can wait a little while. Implementing proper security should not be done via updates or patches "later on" in the project.
    - cglee 14y ago
      There's always a tradeoff between security and other variables. There's no such thing as 100% secure, so where you make your stake in the spectrum of security depends on your business domain. Just as you have different engineering requirements when building a spaceship vs a prius, you have different software practices for different types of projects.
    - slurgfest 14y ago
      Consider physical security against terrorist attacks. You can spend unlimited resources trying to prevent these. But this is subject to diminishing returns, and has other costs.In software projects, too, there IS a point at which it is more rational to trade off security against something else. I would argue that the situation with Rails is analogous to the (historical) situation with Windows. There have been some design mistakes which have opened up more surface area for attacks. But the number of exploits has a lot more to do with market share.
- BSousa 14y ago
  Do you suggest an alternative? That works on Mac/Linux. Is Python/Django that much secure or just not targeted enough? I'm evaluating languages/frameworks for a project and I really want to use Haskell and yesod or happstack, but after starting my project in them, I always end up going back to Rails for the documentation/ease. I may try and stick to it this time but any suggestions would be great.
  - wyuenho 14y ago
    Python.org's been targeted quite enough alright[1]. PyPI is arguably more secure though the surrounding implementations are spotty. You can at least verify the package uploader's identity with some certainty using PyPISSH[2], and sign your package with GPG[3]. The problem is, PyPISSH and signing your package with GPG are not required for compatibility reasons. [1]: http://wiki.python.org/moin/WikiAttack2013 http://wiki.python.org/moin/WikiAttack2013 [2]: http://pypi.python.org/pypi/pypissh http://pypi.python.org/pypi/pypissh [3]: http://pypi.python.org/security http://pypi.python.org/security
  - slurgfest 14y ago
    Much as I prefer Python, I don't think that switching to it just for more security is going to be very satisfying or have a huge return. I submit that security is typically more a function of your project than JUST the language it is written in. For example, I doubt that Haskell's focus on type safety alone will make your programs secure (particularly when you are not enjoying it and are spending more time than you want on issues other than security). You may get more bang for the buck by focusing on security as an issue within whatever language you are using?
- knowtheory 14y ago
  I'm loathe to engage in more negativity, but dude, you're just engaging in software-bigotry and trolling now. You're making broad generalizations about the ruby community and it's members, many of whom do not fit your stereotypes. Has the compromise of Rubygems been an event of such massive proportion that it effects all ruby devs and those who rely upon them? Yeah. Do things need to be fixed? Yes. Can these things be fixed within the Ruby community? Yes. So if you want to advocate that people shouldn't use Ruby or Rails, fine, your prerogative. But please, stop being an asshole while doing it.
  - PommeDeTerre 14y ago
    Your name-calling aside, how do you propose that the Ruby community deal with these inherent problems with their software and their attitudes? Will they do the responsible thing and throw out all of the existing, poorly-written code? Will they collectively ditch RubyGems in favor of a system that has some modicum of security built in from the start? Will they throw out their flawed development philosophies, so that they don't get into the same situation later on? I'm unfortunately inclined to think that we'll just see more of the same. These problems will be "patched" over, at best, rather than fixed at the root. In fact, proper fixing of these issues would go against everything that the Ruby community stands for. That's why I think that moving away from Ruby and Ruby on Rails is a responsible approach. Some problems just can't be fixed, and I think we've encountered some of those in this situation.
    - knowtheory 14y ago
      Yeah, see, you can't put the name calling aside. That's what i'm telling you. Regardless of the merits of a discussion regarding security, open source software, and the ruby community, it's clear that you have an axe to grind, and are not participating in this conversation in a constructive manner. There is no point in engaging you in a discussion about Ruby security, because you just want people to stop using Ruby. Again, that's your prerogative, but don't try to dress it up as your overwhelming concern for security. The practical matter is that folks are going to continue using Ruby with 100% certainty for the short term. So if you were actually interested in security, rather than trolling or gloating, you could actually comment on the technical matters under discussion, instead of just telling people "stop using ruby" and that the "proper fixing of these issues would go against everything that the Ruby community stands for."
- rimantas 14y ago
  > We see far fewer of these kinds of issues arise when > things are not done the "Ruby" way. But not because other ways are safer and products are safe. They are just not as interesting for the HN crowd.
- static_typed 14y ago
  Finally someone else gets it. Security is not solved by a gem install makerailsmadsecurer. Security is a process, and it does not stop. How many people install gems happily without really understanding what it actually permits? Especially when run as root? How many people understood the always-on, Yaml parser approach that has been responsible for some of the recent security issues in Ruby land? Given it is possible to write secure software and frameworks, why don't we see this in Ruby land?

by qrush 14y ago

PommeDeTerre 14y ago

Another approach is to completely move away from using Ruby, Ruby on Rails and related software. I think that the recent security issues are evidence of many systemic problems within the Ruby community, and with their approach and attitude toward software development. Security should be inherent and considered from the very start, rather than brought on over time by an endless stream of patches and updates. Furthermore, the focus should not be on cranking out libraries and code as quickly as possible, especially when said code is rife with security holes. There are many other programming languages, libraries and communities that take a far more sensible approach to software development. We see far fewer of these kinds of issues arise when things are not done the "Ruby" way.

phillc 14y ago
Your philosophies are sound for banking software. There are cases where startups, social impact organizations, or any fast moving team would pick rails for its fast movement, accessibility, and support, even if they thought that there were even more security issues than that have happened.
- PommeDeTerre 14y ago
  That's a very dangerous attitude to have. Security is not something that should be traded off just to reduce development time or effort slightly. Regardless of the situation, it's much more responsible to focus on doing security properly, while cutting corners on the UI, documentation or other less-critical areas of the application. Those are generally the kind of updates that can wait a little while. Implementing proper security should not be done via updates or patches "later on" in the project.
  - cglee 14y ago
    There's always a tradeoff between security and other variables. There's no such thing as 100% secure, so where you make your stake in the spectrum of security depends on your business domain. Just as you have different engineering requirements when building a spaceship vs a prius, you have different software practices for different types of projects.
  - slurgfest 14y ago
    Consider physical security against terrorist attacks. You can spend unlimited resources trying to prevent these. But this is subject to diminishing returns, and has other costs.In software projects, too, there IS a point at which it is more rational to trade off security against something else. I would argue that the situation with Rails is analogous to the (historical) situation with Windows. There have been some design mistakes which have opened up more surface area for attacks. But the number of exploits has a lot more to do with market share.
BSousa 14y ago
Do you suggest an alternative? That works on Mac/Linux. Is Python/Django that much secure or just not targeted enough? I'm evaluating languages/frameworks for a project and I really want to use Haskell and yesod or happstack, but after starting my project in them, I always end up going back to Rails for the documentation/ease. I may try and stick to it this time but any suggestions would be great.
- wyuenho 14y ago
  Python.org's been targeted quite enough alright[1]. PyPI is arguably more secure though the surrounding implementations are spotty. You can at least verify the package uploader's identity with some certainty using PyPISSH[2], and sign your package with GPG[3]. The problem is, PyPISSH and signing your package with GPG are not required for compatibility reasons. [1]: http://wiki.python.org/moin/WikiAttack2013 http://wiki.python.org/moin/WikiAttack2013 [2]: http://pypi.python.org/pypi/pypissh http://pypi.python.org/pypi/pypissh [3]: http://pypi.python.org/security http://pypi.python.org/security
- slurgfest 14y ago
  Much as I prefer Python, I don't think that switching to it just for more security is going to be very satisfying or have a huge return. I submit that security is typically more a function of your project than JUST the language it is written in. For example, I doubt that Haskell's focus on type safety alone will make your programs secure (particularly when you are not enjoying it and are spending more time than you want on issues other than security). You may get more bang for the buck by focusing on security as an issue within whatever language you are using?
knowtheory 14y ago
I'm loathe to engage in more negativity, but dude, you're just engaging in software-bigotry and trolling now. You're making broad generalizations about the ruby community and it's members, many of whom do not fit your stereotypes. Has the compromise of Rubygems been an event of such massive proportion that it effects all ruby devs and those who rely upon them? Yeah. Do things need to be fixed? Yes. Can these things be fixed within the Ruby community? Yes. So if you want to advocate that people shouldn't use Ruby or Rails, fine, your prerogative. But please, stop being an asshole while doing it.
- PommeDeTerre 14y ago
  Your name-calling aside, how do you propose that the Ruby community deal with these inherent problems with their software and their attitudes? Will they do the responsible thing and throw out all of the existing, poorly-written code? Will they collectively ditch RubyGems in favor of a system that has some modicum of security built in from the start? Will they throw out their flawed development philosophies, so that they don't get into the same situation later on? I'm unfortunately inclined to think that we'll just see more of the same. These problems will be "patched" over, at best, rather than fixed at the root. In fact, proper fixing of these issues would go against everything that the Ruby community stands for. That's why I think that moving away from Ruby and Ruby on Rails is a responsible approach. Some problems just can't be fixed, and I think we've encountered some of those in this situation.
  - knowtheory 14y ago
    Yeah, see, you can't put the name calling aside. That's what i'm telling you. Regardless of the merits of a discussion regarding security, open source software, and the ruby community, it's clear that you have an axe to grind, and are not participating in this conversation in a constructive manner. There is no point in engaging you in a discussion about Ruby security, because you just want people to stop using Ruby. Again, that's your prerogative, but don't try to dress it up as your overwhelming concern for security. The practical matter is that folks are going to continue using Ruby with 100% certainty for the short term. So if you were actually interested in security, rather than trolling or gloating, you could actually comment on the technical matters under discussion, instead of just telling people "stop using ruby" and that the "proper fixing of these issues would go against everything that the Ruby community stands for."
rimantas 14y ago
> We see far fewer of these kinds of issues arise when > things are not done the "Ruby" way. But not because other ways are safer and products are safe. They are just not as interesting for the HN crowd.
static_typed 14y ago
Finally someone else gets it. Security is not solved by a gem install makerailsmadsecurer. Security is a process, and it does not stop. How many people install gems happily without really understanding what it actually permits? Especially when run as root? How many people understood the always-on, Yaml parser approach that has been responsible for some of the recent security issues in Ruby land? Given it is possible to write secure software and frameworks, why don't we see this in Ruby land?