Yes We Can. Ruby "require" over HTTP, That Is. | Hacker News Reader

Yes We Can. Ruby "require" over HTTP, That Is.

blog.astrails.com

12 pointsVitaly16 comments

How is this a win? Is anyone actually surprised that you can rig this up? I don't think technical difficulty has been the big obstacle to this feature.

Yea, you actually should never do this. PHP actually has this 'feature' out of the box: http://us2.php.net/manual/en/function.include.php (see Example #3)

ok. security. everyone is soooo concerned about it...

A few questions for you:

* When was the last time you personally verified gem sources that you built and installed?

* did you ever install software not from the big known sources that are verified on the OS level?

* did you ever install a gem from github (do you even know you are talking to github?)

* "wget http://somewhere/archive.tgz; tar zxf archive.tgz;cd archive;sudo make install" anyone?

* rails -m http://github.com/some_cool_template.rb?

* do you cryptographicaly sign your own sources and verify the signature during production deployments?

May be http_require is just for you. if you "failed" on any of the above, you might to be as ignorant over casual security as I am :). Security is always a tradeoff with convenience. When you consider the effort required to actually perform a man in the middle attack or some other kind of attack when you install something from github versus how hard is it to just break into your house and steal the laptop you might just decide that running some code directly from github might not be such a bad idea :)

But more importantly, the intended usage is over a secured network. vpn, ssh or ssl tunnel or even http://localhost (serving from protected directory with some ACL). I can think of many many situations where this is just 'right'.

The standard capistrano/vlad way of delivering the sources is rsync or git over ssh (or even SVN over HTTP!) How is this more secure then fetching a source over http though the same ssh tunnel (forwarded localhost, i.e. SSH -L...)?

There's a difference between not following best practices and precluding yourself from doing so.

How exactly you are precluding yourself from doing anything by using http_require?

http_require is equivalent from the security standpoint to doing 'wget ...;..;make install' and myriad other less then secure things we do almost everyday (including on production server. how did you install sphynx last time around? did you check any signatures). http_require can be used in similar ways with same security effect. saying that http_require is somehow inherently less secure then those everyday tools is somewhat hypocritical :)

You would never curl -O && make install in a best-practices deployment, so comparing http_require to "not checking signatures" is apples/oranges.

I don't think you'd want to, though. They seem willfully ignorant about the myriad security problems with this. Especially, since they say "it's no worse than downloading the code and then executing it."

The underlying assumption is that when you load "http://example.com/foo.rb ", you are example.com. Thus, it is not really a security problem, unless of course your data center is already compromised.

[Edit: I noticed a bug. The " at the end of the URL is eaten (won't even show up in the edit box after submitting) unless there is a space there. Oops.]

This increases the amount of harm a man-in-the-middle attack can do, also (though only if the attacker is after you, specifically, or at least people who blindly require & execute ruby code).

Yes, DNS poisoning could be bad. It does add a lot of complexity to your application without adding much in the way of features.

One solution could be to compare the downloaded file with an expected hash. That'd at least give you the opportunity to audit the code once. Something like...

require 'http://example.com/somelib.rb, '7361c1132d2ada0e987080100cfff5c1645c5e7d'

Another solution would be somthing like what arc does: only download the file once and cache the result. http://catdancer.github.com/lib.html

Q: What happens when you combine this with the default Ruby OpenSSL certificate verification level? (Hint: the default verify setting is 'none'.)

I'm also not sure this is worth an entire blog post, given how little code is required to implement it:

  require 'open-uri'

  module Kernel
    alias :_orig_require :require
    def require(mod)
      mod =~ %r{^https?://} ? eval(open(mod).read) : _orig_require(mod)
    end
  end

Edit: I should have phrased that a little more constructively. My point was not to suggest that small snippets of code are unworthy of blog discussion; rather, it was to show that the code in question really was equivalent to any case of 'eval' applied to untrusted input. I.e., a Bad Idea.

Pretty sure that _why did this about 3 years ago?

Yep! http://redhanded.hobix.com/inspect/requireThin_ice.html

This does prompt an interesting question, with repositories like github where there is a built in trust model, maybe this will actually be the norm at some point?

See this is the thing: Ruby was just getting too fast so he needed some way to slow his code down so that he could go back to focusing on "scaling" again.

Reply on news.ycombinator.com