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

[FooBarWidget]

You're right, I totally didn't think about that. Securing the C compilation system could give a false sense of security.

What we should have instead is a good signing infrastructure to detect when trusted gems have been tampered by a third party.

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

[Xylakant]

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.