Add support for editing of Ruby language (non-RubyGem) advisories in GHSA database

[jasnow]

Add support for editing of Ruby language (non-RubyGem) advisories in GHSA database.

 * jruby: https://github.com/advisories?query=jruby+ (23)
 * mruby: https://github.com/advisories?query=mruby  (40)
 * ruby-lang: https://github.com/advisories?query=ruby-lang (86)
TOTAL: 143

Looks like their is 5 non-rubygems, non-ruby-language advisories, 
but we can deal with them separately.
 * Unreviewed "ruby: https://github.com/advisories?query=ruby+type%3Aunreviewed (148)

I tried to add missing information to some of them lately and was blocked
by not having an "ECOSYSTEM" value for them.

I propose something similar to "Ruby Languages" or "Rubies" be added
as a possible "ECOSYSTEM" value.

The "PACKAGE" value could be ["ruby-lang", "jruby", "mruby", "rbx/rubinius", "truffleruby", etc].

A good reference for other possible "PACKAGE" values at https://github.com/codicoscepticos/ruby-implementations
Thanks.

[jasnow]

Another reason to do this addition is to support the "Security advisories • Enabled
associated with ruby-related repos, such as: https://github.com/jruby/jruby/security which is currently empty.

[joshbuker]

See also: https://github.com/rubysec/ruby-advisory-db/tree/master/rubies

[oliverchang]

Hey @jasnow, thanks for reaching out!

Adding a "Rubies" ecosystem certainly is an option, but there's a complexity there in that we have to define the set of valid versions for these.

However one of the key motivations for the OSV schema here is ensuring consistency in formatting, while avoiding building a custom registry where we can (instead deferring to existing open source ecosystems).

I also proposed a more generic approach in #94 (comment): thoughts on this as a more general approach that will generalise to all programs?

[oliverchang]

Another alternative is just leveraging the existing GIT metadata fields for identifying these, since it can be hard to define consistent rules for version numbers and naming.

e.g. GSD already does this for the Linux kernel:

https://github.com/cloudsecurityalliance/gsd-database/blob/150921f63987cabdc5e2924a7f255554a3f13bf6/2023/1000xxx/GSD-2023-1000890.json#L46

Would that work for the ruby cases here?

[oliverchang]

More examples here from OSS-Fuzz:

https://github.com/google/oss-fuzz-vulns/blob/main/vulns/mruby/OSV-2020-744.yaml

(Note the "package" field is completely optional, despite these examples having them).

id: OSV-2020-744
summary: Heap-double-free in mrb_default_allocf
details: ...
modified: '2022-04-13T03:04:39.780694Z'
published: '2020-07-04T00:00:01.948828Z'
references:
- type: REPORT
  url: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23801
affected:
  ranges:
  - type: GIT
    repo: https://github.com/mruby/mruby
    events:
    - introduced: 9cdf439db52b66447b4e37c61179d54fad6c8f33
    - fixed: 97319697c8f9f6ff27b32589947e1918e3015503
  versions:
  - 2.1.2
  - 2.1.2-rc
  - 2.1.2-rc2
  ecosystem_specific:
    severity: HIGH

[joshbuker]

I wonder if @reedloden or @postmodern would have any thoughts on the best way to identify Ruby binaries?

[jasnow]

The focus of this specific issue is no one can currently edit the "unreviewed" non-RubyGems advisories
in the GHSA database because there is no appropriate value to select under "Ecosystem".

Here is my first try to ask for GHSA to help me help them.
github/advisory-database#1796

[jasnow]

OSV-2020-744

Is there any linkage to a CVE number for these records?

[jasnow]

I wonder if @reedloden or @postmodern would have any thoughts on the best way to identify Ruby binaries?

My guess at an answer would be:

Given ["cve-", "ghsa-", "osvdb-"] numbers as linkage and
    GHSA-Ecosystem                        RAD
.........................................................................................
    RubyGems                     then directory would be "gems" and "gems:" field would be  <gem-name>
    NEWRUBYLANGS                 then directory would be "rubies" and "engine:" field would be  <lang-name>
    
Else currently unsupported in RAD (ruby-advisory-db)

More details at: https://github.com/rubysec/ruby-advisory-db/blob/master/lib/github_advisory_sync.rb

[postmodern]

@joshbuker From reading the original issue, I feel like "Ecosystem" is being used to describe things such as npmjs.com and rubygems.org. Software such as ruby, mruby, jruby, rbenv, etc, should be considered standalone pieces of software that can be installed directly or via apt/brew/etc. I feel like the whole point of "Ecosystem" is really to help distinguish between an npm package from a non-npm package, if they happen to share the same name. Therefor, I think "Ecosystem" should not be a required by GHSA for MRI/CRuby, jruby, truffleruby, mruby advisories when suggesting edits.

mruby might be an in-between case, since while it does come with it's own set of builtin mrbgems which are compiled into the resulting mruby static library, you can also add 3rd party mrbgems which there are a few. So maybe an additional ecosystem of mrbgems as opposed to rubygems might be necessary for advisories for specific mrbgems libraries (read: not mruby itself).

[kurtseifried]

This also relates to what is our upstream policy?

CloudSecurityAlliance/gsd-tools#178

E.g. should we extend the list of ecosystems to provide better coverage, ideally getting it into OSV, but forking it if needed?

[joshbuker]

@postmodern

I feel like the whole point of "Ecosystem" is really to help distinguish between an npm package from a non-npm package, if they happen to share the same name.

This is a good point; Ecosystem is more for avoiding namespace issues than anything else.

Is there a way we could represent what ruby-advisory-database does with its custom schema in OSV? Ideally, in a way that scales for other ecosystem equivalents as well.

Perhaps an Ecosystem of Standalone or Binary would be appropriate? And the package name could be either jruby and/or the direct URL to the project/git repo, for example.

Mostly thinking aloud.