4 ms·
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
by Nyarly 17y ago
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."
- jrockway 17y agoThe underlying assumption is that when you load "http://example.com/foo.rb 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.]
- lanaer 17y agoThis 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).
- jrockway 17y agoYes, DNS poisoning could be bad. It does add a lot of complexity to your application without adding much in the way of features.
- ontilt 17y agoOne 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 http://example.com/somelib.rb, '7361c1132d2ada0e987080100cfff5c1645c5e7d'
- cninja 17y agoAnother solution would be somthing like what arc does: only download the file once and cache the result. http://catdancer.github.com/lib.html http://catdancer.github.com/lib.html