

Ruby gems are still not safe to use - cbetta
http://cristianobetta.com/blog/2013/02/02/ruby-gems-are-not-safe-to-use/

======
qrush
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
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.

~~~
knowtheory
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
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.

~~~
moe
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.

~~~
wyuenho
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.

[http://www.cvedetails.com/product/22569/Rubyonrails-
Rails.ht...](http://www.cvedetails.com/product/22569/Rubyonrails-
Rails.html?vendor_id=12043)

[http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-
On-...](http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-
Rails.html?vendor_id=12043)

------
taf2
"Stop running code on gem install."

\- 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...](http://web.archive.org/web/20090211040821/http://www.idle-
hacking.com/2008/05/i-say-cap-you-say-rpm-i-cap-your-rpm/)

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 )...

~~~
Xylakant
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.

~~~
h_r
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)

~~~
FooBarWidget
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.

------
grandalf
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.

------
ef4
Worrying about code execution at install is silly. The whole point of
installing a gem is to download code that you're going to execute.

So the whole gem (install code and runtime code) needs to be trusted, and
should be verifiably signed by somebody you can trust.

~~~
static_typed
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.

The whole design needs a rethink.

~~~
Xylakant
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.

------
nicholasjarnold
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?

~~~
oscardelben
yes, all gems have been verified.

~~~
nicholasjarnold
Thank you.

------
hopsoft
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.

------
mark_l_watson
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.

------
curcumin
This hyperbole is very silly! Weaknesses appear in everything when it becomes
popular.

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.

------
helloamar
Then y many are giving lot of hype?

~~~
tr4656
Because Ruby is something they use and they want to fix the problem. If they
don't highlight the problems, nothing will get solved.

