Replies: 1 comment 4 replies
-
|
I don't think we plan to backport the change (#1733) to Rack 2, as it breaks backwards compatibility. @ioquatix @tenderlove your thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps a 2.x version with a string suffix? Assuming this will allow users with gems that require rack < 3 to still request a |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think we should backport this, but I seem to recall there was a monkey patch floating around to fix this. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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.xorrack < 3in their manifests, such as:rack3 sinatra/sinatra#1797), which is blocked by the rainbow dependency, which I am not sure is even maintained anymore, andBeta Was this translation helpful? Give feedback.
All reactions