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.
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.
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.
You're making broad generalizations about the ruby community and it's members, many of whom do not fit your stereotypes.
His generalizations fit well enough to include the dev teams of the core package management system and the by-far predominant application framework. As broad generalizations go that's a pretty effective reach.
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.
Yeah.
Do things need to be fixed? Yes.
Yes.
Can these things be fixed within the Ruby community? Yes.
Woah, hold your horses there. Can they be fixed within a Ruby community? Yes. Can they be fixed within the community as it now stands, with its present culture and practices? I would hesitate before answering yes.
But please, stop being an asshole while doing it.
Turned out Walter was right, in the end. She did kidnap herself.
Right, so it's perfectly possible to be both right, and an asshole.
I don't begrudge people being right (although, I also don't happen to think that Mr. Potato there is totally correct). I do however have a problem with people being jerks.
Moreover, being right does not give someone license to be a jerk either.
-----------------------------
As for the substance, yeah I do think there are ways to secure Ruby gems better, and I think that given the way the Ruby community is organized (since it's not a monolith), there are paths forward that can be organized and implemented by smart and interested rubyists, and those paths can and will be adopted by the bulk of developers who aren't as engaged in the Ruby ecosystem.
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.
I see your comments on every Ruby-related thread and you sound like a broken record.
Many of us Ruby-users see the problems in a similar way and try to fix them. It's a learning process and it happens right now. The ruby community is also not an uniform blob. We are not 37signals and we are not the rubygems team. Many of us disagree with some decisions made at these places. Most of us also use other languages and are well aware of the trade-offs that Ruby implies.
This is all worth discussing and the specific problems are worth fixing. The rubygems-team happens to be working on their problem, which is a hard problem, right now; https://gist.github.com/4696144
Your mindless bashing on every Ruby HN-thread contributes nothing. Please use your time for something more productive, e.g. you could go to your preferred language community and help them fix their security problems, which they also have plenty of.
I'd reeeaally like to see a second group of dedicated maintainers that are more concerned about security to step up to the plate, fast. The guys behind Ronin are doing great, but they are really just 2 guys battling against a community which have a track record of producing a code base that has had 8 code execution and 8 SQL injection vulnerabilities so far.
Ok, serious question: In which ways is rubygems less safe than .deb packages, .rpms, portfiles or ebuilds, python eggs, jars or composer files? All of those are mechanisms to distribute and deploy code. All of those suffer from the same basic vulnerability: They ship code that gets executed. If that code gets compromised, you have a viable attack. Debian saw its developer repositories compromised at least in 2006 [1] and back then, we had the same problem: In the beginning nobody was sure whether the package repositories had been attacked.
There is one critical difference between OS package repos and the programming language repos: For an OS package repo, signing is mandatory. Programming language repos allow that, but don't enforce it. Python is a little ahead here, but this is nothing that can't be fixed. I actually see that gem signing will be mandatory in the foreseeable future.
Without disagreeing with you substantively, Python eggs have not been the main way Python packages are distributed for years now. This is not to say that PyPI couldn't use some attention to issues like signing!
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."
You might want to stop and consider who's "not participating in this conversation in a constructive manner". You've called him a "software-bigot", "troll", "jerk" and "asshole". You seem to be taking his valid criticism personally. I've re-read the post and cannot see your motivation for the name calling.
The Ruby community may come out of this better and stronger but it's quite valid to suggest that some people may be better off moving on.
And he really isn't participating in a constructive manner. He gets away with his obnoxious behavior in other threads by intermingling his opinions and generalizations in with the substantive discussion.
I'm not going to engage him on the substance of what's happening in the Rubysphere, because he has made clear that he no intention of helping either move the discussion along, or to solve any problems.
That he occasionally raises legitimate points is irrelevant, others have raised the same points in constructive manners, and there have been fruitful discussions on the topics. Engaging this particular guy is only feeding a troll who is distracting from the conversation.
Regretfully there are two opposing goals that must be served here.
The discussion about how Rubygems is going to move forward is really of vital importance to the ruby community. Making sure that there is a civic engagement with Rubygems and the tooling that Rubyists rely on is something that really does need to be promoted better.
On the other hand, Pomdeterre's trolling is obnoxious and unhealthy behavior that HN shouldn't tolerate. Like I said above. Being right is important, but it's not the only important thing. You can be right and still be an asshole who's being a drag on a community, or an organized effort to do something.
I agree that my criticism of PomDeTerre's behavior does not touch on the heart of the discussion, but I hope you can understand that that was in fact the intention. It is not the subject matter that he is discussing that's the problem. It is his conduct.
It's unfortunate that it's distracting from the substantive discussion, but we shouldn't have to put up with people acting like this, or interfering with efforts to fix problems.
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.
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.
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?
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 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.
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.
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.
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?
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
)...
You don't have to install with root permissions. If you run as normal user it will install to the home directory instead. But many people want to install gems system-wide so they install with sudo.
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.
I don't see the big gain in stopping to run code on install. By definition, we install gems to run code. If we don't trust the gem author not to mess with our system on install, how can we trust him not to mess with our system when we use the gem? Granted, there might be some people that install gems as root and run them as unprivileged user only, but even as a non-root user it's a problem to run code you don't trust.
Well... you would have to trust both the gem author and those who might have compromised an author's credentials. And my understanding is that the install can easily be running under a different set of credentials than normal use. (not a Ruby or Rails user here)
You don't need root to do serious damage. Even if you secure the gem installation process, the code inside the game can just do damage later. I think a signing system to prevent third party tampering of gems is the best that any developer packaging system can do.
It's more standard to have rails apps run under a dedicated and lower privileged user than not. It's also a common option to use vendored dependencies for a variety of reasons: You (a) avoid conflicts with other installed gems on the system and (b) don't need elevated privileges to install the app. But let's not just talk about rails: There's a ton of tools that use ruby to manage stuff, some of them running as root by default - both chef and puppet are written in ruby and sometimes distributed as gems. In any case, they use gems. So all it needs is to have one binary exploited to start a shell and then you have an entry point from where you can escalate privileges and obtain root. So if you don't trust rubygems you can't install anything in ruby.
Even if 5% of the rubygems ecosystem contained malware, the biggest danger to most projects is the inclusion of gems that are sloppily maintained. Just because something is released as a gem does not mean it has good code quality or that good development practices were used to create it.
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.
Right. Some of these are legitimate issues, but not that one.
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).
I think the overall points raised help shape the bigger conversation about the current state and implementation of Ruby Gems.
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.
But isn't that a problem where no good solutions exist? We share code to reuse code. If we insist to allow only one level of dependencies, then we restrict code reuse which is bad in other ways: you promote reimplementation of functionality, more often bad than good.
Is it safe to install rails with something like 'gem install rails' right now? I'm totally new to Ruby and to the Rails framework, but I was going to start a side project with it this weekend (today). Any advice on how I can safely get setup while the community is figuring out how to cope with the intrusion?
Removing the ability to run code on gem install would be quite disruptive. I think that establishing a universal gem signing policy and/or some form of whitelist/blacklist strategy would be a better solution. Consumers need to be able to trust the installations of the tools they use. The same risks apply to any other installation process. Think of how we install RVM or Homebrew.
Sorry in advance for being off topic, but: I rely a lot on Clojure repos like clojars.org and I in addition to checking my few Rails and Sinatra apps in the last few days, I have become a little concerned about the same sort of thing happening with clojars, main mavin repos, etc.
