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.
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.
> We see far fewer of these kinds of issues arise when
> things are not done the "Ruby" way.
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.
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.
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?
- this is a real issue. I've used rpm shell execution to modify sshd as well as other system components in order "install" additional software. http://web.archive.org/web/20090211040821/http://www.idle-ha...
as you can see from that archived post, it's very important to have trust of what you are installing. especially when you have to install with root permissions....
Seeing how many references exist to "sudo gem install blah"... this is very serious as it's a high reward if you're able to get your remote code executing with root privileges (assuming as most would not limit sudo access e.g. user ALL=(ALL) ALL )...
The real problem is executable code. Building C extensions typically require invoking arbitrary commands. The problem is also not unique to RubyGems: RPMs and DEB packages have preinstall and postinstall scripts, and they require root privileges.
I think a good solution would be to to run C extension compilation code as a sandboxed non-root user. If a RubyGem is being installed as a normal user, the compilation code should still be run as a separate, sandboxed user, to prevent it from messing with the user's home directory. Any build products that the compilation process generates will be copied over the destination directory. The sandbox user's home directory would be wiped after every installation.
This would severely limit the C extension building system's power (they can't generate files outside the gem directory etc without being wiped) but I think that's acceptable. Use cases that require more power can rely on external user-invoked commands, e.g. passenger-install-apache2-module.
What we should have instead is a good signing infrastructure to detect when trusted gems have been tampered by a third party.
So the whole gem (install code and runtime code) needs to be trusted, and should be verifiably signed by somebody you can trust.
Given that the Ruby code in the gem has full access to the file system with the privileges of whoever is running it, I don't see how this makes things any worse (assuming you're not installing the gems as root or whatever).
Who built your Gem? How do you verify that still holds? You may trust developer A who released a nice Gem, but what about when he pulls in a dependency, that pulls in another dependency, and suddenly you have gems from developer B, who loves to stick a Yaml parser out there for all to compromise.
The whole design needs a rethink.
The default behavior of bundler is to grab the latest compatible gem version, and in many cases this breaks things bc of little or no QA on the part of some gem maintainers.
The top 10% of gems are well maintained but the rest should generally be avoided.
There needs to be something like the "app store" and I don't mean specifically apples' own.
But we need some of the big corps using ROR to step forward and provide complete support for this type of project.