On Jan 16, 2007, at 14:11, Paul Duncan wrote: > Easy is certainly subjective, but there are a couple ways to "fix" the > documentation hole: > > * RubyGems could pre-generate documentation and just copy it into > place (I don't like this solution; it makes gems significantly > larger). > * RubyGems should create an initial documentation directory > elsewhere, then drop root permissions (maybe even chroot() as well) > and generate the documentation as a user with no privileges in the > safe location, then move the generated documentation into place. > > The second option is preferrable, and it's actually a lot easier to > implement than it sounds. I have a half-working patch that I can > clean > up and submit if there's any interest. Basically it just creates a > copy > of the source in a temporary directory, then forks a child > process which chroot() itself and drops it's permissions before > generating any documentation. The parent waits for the child to exit, > then copies the generated documentation into place.
Can you post this one to the tracker? > Unfortunately that doesn't really fix much of anything, because it > only > closes off the huge security hole in documentation generation. It > doesn't prevent a malicious user from trojaning an existing gem and > adding files or replacing legitimate code with pretty much > whatever they want. > > The _really_ bad news is this type of attack became a whole lot easier > once RubyGems started using mirrors. Instead of worrying about a > malicious user breaking into one machine (rubyforge.org), we now > have to > worry about them breaking into N machines, where N is the number of > Gem mirrors. > > The only way to completely eliminate this type of attack would be to > force gem authors to sign their gems, create an author certificate > distribution mechanism (or tie it to some sort of existing trust > mechanism like X.509 or PGP keyservers [1]), remove all the unsigned > gems from the Gem repositories, and (finally) enable signature > checking > by default in RubyGems. > > Frankly, I don't see all of that (or any of it, really) happening any > time soon. Could we mitigate that by including a list of SHA1s of packages on the rubyforge gem server, and use it to validate packages from mirrors? > The idea behind all the above steps is to assume the contents of > packages can and eventually will be tinkered with, and to provide a > way > for users to be reasonably certain that nothing fishy has happened to > packages once they're out of the authors' hands and on the Gem > repositories. -- Eric Hodel - [EMAIL PROTECTED] - http://blog.segment7.net I LIT YOUR GEM ON FIRE! _______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
