Re:Yes We Can. Ruby "require" over HTTP, That Is.
by Nyarly on Tuesday May 12, 2009 @02:33PM
(#605927)
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."
[ Parent
| on HN ]
Re:Yes We Can. Ruby "require" over HTTP, That Is.
by jrockway on Tuesday May 12, 2009 @02:49PM
(#605948)
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.]
Re:Yes We Can. Ruby "require" over HTTP, That Is.
by lanaer on Tuesday May 12, 2009 @02:52PM
(#605957)
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).
Re:Yes We Can. Ruby "require" over HTTP, That Is.
by jrockway on Tuesday May 12, 2009 @04:18PM
(#606101)
Yes, DNS poisoning could be bad. It does add a lot of complexity to your application without adding much in the way of features.
Re:Yes We Can. Ruby "require" over HTTP, That Is.
by ontilt on Tuesday May 12, 2009 @04:26PM
(#606110)
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'
Re:Yes We Can. Ruby "require" over HTTP, That Is.
by cninja on Tuesday May 12, 2009 @04:45PM
(#606139)
Another solution would be somthing like what arc does: only download the file once and cache the result.
http://catdancer.github.com/lib.html