Bugs item #29236, was opened at 2011-05-30 13:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126
Category: `gem install` command (extensions) Group: next Status: Closed Resolution: Rejected Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Ryan Davis (zenspider) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2011-06-01 01:01 Message: What I think is only what I think. I'm not saying it's right. I'm not sure whether preventing it or reporting it would be the better choice, were we to implement a programmatic solution. In our case, seeing a message saying "installing rake-0.9.0" would have saved the hair of a small herd of yaks. That said, if the docs on mkrf_conf.rb are loud and clear and in a place that people will look and find them, it seems like overkill at that point to then put a programmatic solution in place as well. Also, totally agree that a programmatic solution wouldn't solve the problem of maliciousness. I say leave it be, document it, and if it happens again we can revisit. ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 00:38 Message: The issue is largely a question of how would rubygems limit what a gem can do to build it's extension. The only primary thing we could do would be to pass an environment variable down which would say "you're building an extension now" so that gem could bail out in this case. But that would largely only protect people who did it accidentally and not those who are doing it maliciously (since they could simply remove the env var first). Do you think only have it exist as an advisement is good enough? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-06-01 00:22 Message: This isn't really about spork. It was easy enough to work with spork's maintainer once we figured out it was spork, but narrowing that down took no small effort. My concern is that somebody will do this again in the future and some other team will incur that cost again. I'm not worried about my team incurring that cost because we'll know what to look for :) I'm not going to press on this, but I just wanted to document the wider context. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 23:44 Message: I talked to tenderlove who sent Tim a pull request to change his build/release process entirely and he accepted it. Tim was unaware that you could build platform specific gems and that solves all his issues. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 23:41 Message: I think this is a simple case where the spork gem shouldn't do that and it is easy enough to work with the authors to find a solution that works for them. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-30 15:40 Message: By nature building extensions is a dangerous process. Before rvm-era, doing gem installation involved 'sudo' elevation. extconf.rb is executed directly from Ruby and actions like FileUtils.rm_rf or shell out to `rm` is also possible. The nature of the extconf configuration and compilation make it hard to run on a sandbox/safe level environment. We end trusting gem authors do the right thing, but the problem is knowing that is right and what is wrong, and that is exposed by the lack of documentation and good practices in relation to this. Nick Quaranto started the RubyGems guides with the aim of educate people: http://guides.rubygems.org/ I suck at copy writing (english or my native spanish) so I leave it the ones that are more verse on it. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 15:31 Message: I admittedly am not that knowledgeable about Rubygems' internals, so if you say so. That makes sense, but it also seems complicated and error-prone. While that situation kinda sucked (I was bit by it myself), I'm not sure that any software needs to be written to address this. I'd rather use it as a chance to educate gem developers on best practices, as at worst to 'fix' something like this is a 'gem uninstall rake' away. But I can certainly see the advantages of some kind of warning, too. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-05-30 15:27 Message: `gem` is a rubygems command, so rubygems can know when it's being called, even if it's in a separate process (via setting and checking env vars). ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 14:38 Message: How would one be able to prevent or manage this? mkmf.rb is just a Ruby script, so if it contains a simple `gem install lolz`, it's gonna happen. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
