#49 ✓resolved
Wincent Colaiuta

PATCH: Compatibility macros for Ruby 1.8.5

Reported by Wincent Colaiuta | February 29th, 2008 @ 09:17 AM | in 0.7.1

Ruby 1.8.5 compatibility came up in this thread over at Google groups:

http://groups.google.com/group/t...

Here is a patch making Thin buildable on 1.8.5:

http://pastie.org/159293

Also attaching it.

I think Ruby 1.8.5 compatibility is going to be important for a lot of enterprise users. For me the main reason I want to do this is that my platform, Red Hat Enterprise Linux ships with Ruby 1.8.5; Red Hat is going to support RHEL 5.1 up to 2014, and that means they'll patch Ruby 1.8.5 with security fixes for another 6 years, but they won't upgrade to post-1.8.5.

I haven't yet looked into whether the RHEL Ruby installation includes a fix for the CGI multipart issue.

Comments and changes to this ticket

  • Wincent Colaiuta

    Wincent Colaiuta February 29th, 2008 @ 09:04 AM

    The CGI multipart issue is definitely fixed in all Red Hat-provided Ruby packages for RHEL:

    http://rhn.redhat.com/errata/RHS...

    I'm trying to think of a way that this could be handled, given that a check for a fixed version number (1.8.5 or 1.8.6) in the gem is not enough to determine whether there actually is a vulnerability.

  • Wincent Colaiuta
  • macournoyer

    macournoyer February 29th, 2008 @ 10:05 AM

    • Milestone set to 0.8.0
    • State changed from “new” to “open”

    nice job Wincent, I'll check that out and maybe require the cgi_multipart_eof_fix if needed.

  • macournoyer

    macournoyer February 29th, 2008 @ 10:33 AM

    I see no other way then looking at the Ruby version number (apply of < 1.8.6).

    I don't think it you cause any trouble if we require the gem even if the Ruby version was already patched.

    Let me know if you got a better solution.

  • Wincent Colaiuta

    Wincent Colaiuta February 29th, 2008 @ 10:30 AM

    Yeah, I'm trying to think of one... but nothing springs to mind just yet. Brainstorming here: leave it up to the user to install the gem if they need it? print a warning at startup if Thin thinks the gem might be needed but it's not present on the system? provide a config file override to silence the warning if the user is sure that it's not a problem?

    I guess it's up to you whether you think that kind of effort is worth it to avoid the overhead of loading an unneeded gem; personally, I don't really like the idea of overwriting code like that unless it's necessary. Strikes me as being a bit brittle.

    Looking at the Gem source:

    http://mongrel.rubyforge.org/bro...

    It basically looks like they just overwrite the original method with a fixed one. (I notice that they conditionally check for JRuby in the RUBY_PLATFORM variable; I don't know whether it would be worth doing a similar check for RHEL.)

    For comparison, here is the patch that Red Hat already includes with their Ruby packages:

    https://bugzilla.redhat.com/atta...

  • macournoyer

    macournoyer March 2nd, 2008 @ 02:56 PM

    • Milestone changed from 0.8.0 to 0.7.1
    • State changed from “open” to “resolved”

    Applied http://github.com/macournoyer/th...

    Also I loaded cgi_multipart_eof_fix if Ruby 1.8.5, reopen if you have a better solution

    thx for the patch!

  • Wincent Colaiuta

    Wincent Colaiuta March 2nd, 2008 @ 06:15 PM

    Well, I think you're solution is probably fine. Those of us who have a patched version of 1.8.5 like me can just ignore the warning in the log.

    (Not sure if commenting will re-open the ticket... just wanted to say it looks good.)

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Attachments

Pages