Fix check for rubygems vulnerabilities #35
Conversation
| @@ -18,28 +18,28 @@ | |||
| expect(subject.all? do |result| | |||
| result.advisory.vulnerable?(result.gem.version) | |||
| end).to be_truthy | |||
| expect(subject.map { |r| r.advisory.id }).to include('OSVDB-120541') | |||
| expect(subject.map { |r| r.advisory.id }).to include('CVE-2015-1855') | |||
There was a problem hiding this comment.
These are the same advisories - ruby-advisory-db changed their IDs to be CVE-*.
vendor/ruby-advisory-db
Outdated
There was a problem hiding this comment.
I think it makes sense to update our vendored copy of ruby-advisory-db along with these changes.
|
Okay, I've updated the changelog and this PR should be good to merge if you want. (Looks like I don't have the power to merge in this repo anymore.) Should we cut a |
|
I've set up a weekly integration test that lives in my repo and alerts me if it fails, for now: https://github.com/mikesaelim/ruby_audit_tests We could eventually migrate that over to this repo, but I figure that I'll iron out the wrinkles in my own repo first, instead of submitting a ton of PRs to fix anything that crops up. 😅 |
Welp, I think the check for rubygems vulnerabilities has been broken since February 2021.
Problem
I was looking around the rubysec/ruby-advisory-db repo while working on #34, and I noticed that the
/librariesdirectory that holds the rubygems advisories was gone. Turns out, it was moved to/gems/rubygems-updatein July 2019, with a symlink pointing from the old location to the new one, and then the symlink was removed in February 2021. So since then, RubyAudit isn't finding any advisories for any rubygems version.The good news is, according to the ruby-advisory-db and rubygems's changelog, there doesn't seem to have been any new advisories/CVEs since March 2019 (rubygems v2.7.9 and v3.0.3). So, theoretically, everyone who had kept their rubygems versions up-to-date in 2021 should not have missed out on any advisories.
Solution
I've pointed the rubygems checks at the new home for rubygems advisories, and updated the specs. Updating the specs also required me to update our vendored copy of ruby-advisory-db (that we only use for testing), since the old copy (from 2016) still stores the advisories in
/libraries. What do you think?I'd also like to set up some automatic way to detect this kind of problem if it happens again. We don't control ruby-advisory-db and they have no duty to inform us of changes that may break our specific implementation... and RubyAudit development is very sporadic, so it's hard for its devs to be vigilant for breaking changes. I first thought about a runtime check, but it'd have to error in order to get the user's attention, and they wouldn't be able to do anything about it, so maybe not. Perhaps we can schedule a github CI integration test to run daily/weekly/monthly, which simulates running RubyAudit with the latest ruby-advisory-db on a bunch of ruby and rubygems version that we know have advisories?