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.
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).
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...
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.
* 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...)?
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 :)
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.
