Backport the fix for SNYK-RUBY-RACK-1061917 to Rack 2.x

[DannyBen]

Similarly to how Rails team always backport security fixes to at least the last two major versions, is there any chance that the rack team would consider doing the same for a while, at least until Rack 3 is more widely accepted as a dependency version?

Currently, I am referring to the vulnerability discovered in SNYK-RUBY-RACK-1061917.

It seems that upgrading to Rack 3 is blocked in a handful of key dependency chains, which use rack ~2.x or rack < 3 in their manifests, such as:

• Sinatra: (Support rack 3 sinatra/sinatra#1797), which is blocked by the rainbow dependency, which I am not sure is even maintained anymore, and
• Rails with Sprockets: https://rubygems.org/gems/sprockets/versions/3.5.2

[jeremyevans]

I don't think we plan to backport the change (#1733) to Rack 2, as it breaks backwards compatibility. @ioquatix @tenderlove your thoughts?

[DannyBen]

Perhaps a 2.x version with a string suffix? Assuming this will allow users with gems that require rack < 3 to still request a 2.2.4.string explicitly. The alternative probably means months of this vulnerability remaining in the wild, as I understand the surrounding ecosystem.

[simi]

Looking at the problem, maybe we can make new 2.2.x release making this configurable and warn with default unsafe value suggesting safe one? That way apps can survive update to new 2.2.x and will just get warning to improve security.

[DannyBen]

If the configuration route is chosen, I am assuming an environment variable will be the medium yes? This would be the simplest way to influence the app, no matter which overlay is making use of rack.

[ioquatix]

I don't think we should backport this, but I seem to recall there was a monkey patch floating around to fix this.