Dealing with unfixed vulnerabilities in gems

[reedloden]

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).

[phillmv]

Yeah. This is something we're thinking about (i.e. #151).

I think right now we're leaning towards a "vulnerable_versions" and we'll figure something out in the next week or two.

[postmodern]

Currently we just omit patched_versions to indicate all versions are affected.

[phillmv]

So, actually, Reed pointed out a bunch of scenarios.

1. 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.

1. 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.

[jasnow]

I think this is addressed by https://github.com/rubysec/ruby-advisory-db/pull/664/files.
If you agree, please close this issue as completed.

[jasnow]

@reedloden and @phillmv - Any update on this issue?