You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What's the best way to handle OSVDB entries / CVE assignments for ruby gems with unfixed vulnerabilities? Specifically, maybe a gem is obsolete / unmaintained and won't ever have a new fixed version, but we want to let people know they are using a vulnerable gem. Another case is when a gem takes too long to fix an issue, but we want to warn users so they are aware (maybe not cause a failure, but at least a warning in those cases).
The text was updated successfully, but these errors were encountered:
So, actually, Reed pointed out a bunch of scenarios.
There's "this version of the code is no longer going to be supported, upgrade ASAP" -> probably warrants its own kind of advisory file. i.e. "Don't use Rails 3 anymore".
Overloading the semantics of patched_versions probably not so great.
Then there's gems that are maintained but the person has a day job / an unmaintained gem but a vuln affects only a specific version. A patch may or may not be coming along. Meantime, avoid using this one version in particular.
What's the best way to handle OSVDB entries / CVE assignments for ruby gems with unfixed vulnerabilities? Specifically, maybe a gem is obsolete / unmaintained and won't ever have a new fixed version, but we want to let people know they are using a vulnerable gem. Another case is when a gem takes too long to fix an issue, but we want to warn users so they are aware (maybe not cause a failure, but at least a warning in those cases).
The text was updated successfully, but these errors were encountered: