From: Jeremy Bopp <jeremy@...>
Date: 2013-06-04T08:10:47+09:00
Subject: Re: Where does Ruby look to load files?

On 06/03/2013 03:47 PM, J. V. wrote:
> It is going to take two days to fix one application alone; We have many 
> web apps on Ruby.  This is a serious hit on time; and I can imagine 
> there are many other out there that have to dedicate resources to this.

You do realize that the change to Ruby that is giving you problems here
was released almost 3 years ago, right?  Upgrading your application's
basic infrastructure after such a lag should be expected to take some
time and effort.  Try to stay calm.  This one has some workarounds
available.

If you would like to avoid large code changes and accept all the risks,
you can play with fire by appending '.' to the library path for Ruby. 
Locate one of the first files loaded by your application, and add this
near the top:

$: << '.'

Now your library search path is as unsafe as earlier versions of Ruby,
and the rest of your application can go about business as before.

> Can anyone explain exactly what the "security risk" was and why the Ruby 
> dev team could simply not leave this alone?

Maybe you already ran across this discussion:

http://stackoverflow.com/questions/2900370/why-does-ruby-1-9-2-remove-from-load-path-and-whats-the-alternative

Read it closely because it does explain the reasoning down in the comments.

Calling require can happen at any time during the execution of your
application.  If require looks in the current working directory of the
application for files to load, it can be tricked into loading the wrong
files or simply failing to load anything at all by the application's
working directory being something other than expected at the time
require is called.  This could be the result of maliciousness, a poorly
coded library, race conditions in threads, the user running the
application from an unexpected location, or anything else that could
trigger even a momentary change of the application's current working
directory.

While the risk may generally be remote, it is real, and requiring the
majority of developers to explicitly exclude the current working
directory from the library path because they don't need it is guaranteed
to fail somewhere along the way.  It's better to start secure and allow
those few who need this functionality to tweak their applications to
enable it or find better methods so that they don't need it either.

Could these changes have been implemented in some way that preserved
backward compatibility?  Maybe so, but the backward compatibility would
eventually need to be removed in the name of security anyway.  Would
your application have been able to make use of that even after 3 years? 
Maybe not.

There was quite a bit of angst at the time this change went live years
ago.  You're just a little late to the party.

> We cannot afford this type of downtime or resources to rewrite an app 
> everytime some yahoo Ruby dev thinks he is being clever by fixing a 
> security risk that is probably a result of irrational fear of some 
> extremely remote possibility of something happening.

I can understand your frustration, but remember that if you truly want
help, casting about insults is not going to garner much assistance. 
Please also consider that in this case you may not actually know better
than the Ruby developers on this particular point.

> I have seen enough of Ruby in the week dealing with it and will be 
> making the recommendation to rip it out entirely because of the 
> maintenance headache associated with it and the Ruby core devs who think 
> things like this are a bright idea.

Best of luck finding an application stack that can be ignored for years
and then upgraded without the need to touch any of your own application
code to account for API changes.  I've been where you are now
personally, and I can tell you that your problems can be summarized as:

1) Lack of understanding of the tools you're using (Ruby and its libraries).
2) An application code base that was allowed to bit rot for too long.

If your team no longer has any Ruby expertise, it probably makes sense
to go with something you know instead.  Unfortunately for you, you'll
still likely have to support your application in its current form while
you rewrite it from scratch.  It would be best to accept that and try to
avoid alienating those who may help you through this in the meantime.

-Jeremy