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

[Turing_Machine]

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

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