+Ruby-sig

bcc fedora-devel

<snip>
>
> Hey, sorry for not getting some of these updated (you also didn't stay on #fedora-ruby long enough for me to respond). I find that updating many of these breaks API, because ruby library authors are really good at fixing security problems while introducing new issues. Many of them I didn't think I could update in EPEL -- for example moving rails from 2.x to 3.x is a HUGE change.
>
> Rubygems got rolled into ruby upstream - so the old rubygems isn't maintained upstream.
>
> Rack I should fix - they are good at compatibility.
>
>
> I also welcome any co-maintainers on these items. I used to use these packages lots from EPEL, at my current workplace I don't really.

Thank you for the reply ! So this depends from one vulnerability to another, but in general we don`t necessarily have to (and according to EPEL guidelines we really shouldn`t) update to next major version just to fix the vulnerability. For example: https://bugzilla.redhat.com/show_bug.cgi?id=731450 is for Rails 2.x in EPEL 5, but backporting a fix (https://github.com/rails/rails/commit/bfc432574d0b141fd7fe759edfe9b6771dd306bd) is easy.

So please respond to my mail from July and we can start working through these - I`m happy to help you with fix for each of these issues.

There's been a slew of fixes for the 2.x branch of rails and friends. Some apply rather easily, others don't. I honestly haven't thought much about it for a while (obviously). It's a bit odd, in that I really doubt that much of anybody is running a rails app from our RPMS in EPEL. Most of the layered products and developers would either bundle it themselves or use software collections, now that they are available.

In reading the discussion on EPEL.next, perhaps some of the fast moving ruby projects should look for a different repository to live inside.