Add gsm: advisory field in support of issue #305; Added 1 brand new GSM advisory

[jasnow]

Add gsm: advisory field in support of issue #305

• Modified the schemas, specs, and README to add "gsm:" advisory field (similar to "ghsa:" field).
• Add GSM-2016-16 advisory

[postmodern]

What happens when this GSM advisory eventually get's assigned a CVE or added to GitHub Security Advisories DB? Will we end up with a GHSA- and CVE- file? Could the github_advisory_sync.rb automatically rename GSM-* to CVE-*/GHSA-*?

[jasnow]

Good questions

What happens when this GSM advisory eventually get's assigned a CVE or added
to GitHub Security Advisories DB? Will we end up with a GHSA- and CVE- file?

I think that the PR#585 lint check's purpose is to flag duplicate advisories.

Could the github_advisory_sync.rb automatically rename GSM-* to CVE-/GHSA-?

We could watch for it and add a feature when it happens.

[postmodern]

I'm hesitant about adding GSM advisory IDs to the database because of one advisory that never got assigned a CVE. bundler-audit would also need to be updated, as it expects either a cve:, ghsa:, or osvdb: ID to be present; otherwise encryptor < 3.0.0 would break bundler-audit.

I reviewed encryptor's GitHub issues's and noted two things:

1. Appears that the maintainer said they would try to request a CVE, but never reported back.
2. Another person did further research and believes the vulnerability is actually in Ruby's openssl library, not the encryptor gem. This might explain why a CVE was never assigned.

Either someone else needs to request the CVE on behalf of encryptor, or maybe a CVE is not needed and GSM-2016-16 might be invalid.

Long-term, I might be open to trying to consume GitLab's Advisory database along with GitHub's Advisory DB and NVD.

[jasnow]

OK