

Yes We Can. Ruby "require" over HTTP, That Is. - Vitaly
http://blog.astrails.com/2009/5/12/ruby-http-require

======
tptacek
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.

------
jcapote
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)

------
Vitaly
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...)?

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

~~~
Vitaly
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 :)

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

------
Nyarly
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
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.]

~~~
lanaer
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).

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

------
rcoder
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.

------
DannoHung
Pretty sure that _why did this about 3 years ago?

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

------
oldgregg
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?

------
trezor
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.

