RubySec numbering system

[mveytsman]

We should stop relying on osvdb and cve ids as canonical identifiers as they may not be always present, as in the case where we get a vuln before it's in either db.

• Add a new field to the schema, rubysec-id
• Come up with numbering scheme. My suggestion is to model after CVE, ala RUBYSEC-2016-00001
• Add a rubysec-ids to past vulns in the database.
• Come up with policy for generating new id numbes are vulns are added. This should be done by the person with commit bit who's accepting the PR.

[reedloden]

How do we track what is the next available ID to use?

For the year assignment, is that the date of the disclosure or date of finding? Depending on that, need to be able to continually add new IDs for previous years as vulnerabilities are found (that we weren't tracking).

Proper CVE-like format would be RUBYSEC-YYYY-NNNN where NNNN is always at least 4 numbers, zero-padded (can be increased beyond that over time).

Does rubysec-id make sense when we use cve and osvdb right now? Perhaps just rubysec for the field? or rsid or something...

[tarcieri]

How do we track what is the next available ID to use?

Each time IDs are assigned, you could check them into a registry file in the repo (perhaps with a note about whom they were assigned to)

[phillmv]

How do we track what is the next available ID to use?

I think we should script something easy to accept PRs with - maybe it'll calc the new id, merge the changes, apply new id then push the merged results, rather than just using GH.

For the year assignment, is that the date of the disclosure or date of finding?

I vote disclosure. Keep it simple.

Does rubysec-id make sense when we use cve and osvdb right now? Perhaps just rubysec for the field? or rsid or something...

I'd propose RBS-YYYY-NNNN and keep it rubysec or rubysec-id.

In my heart of hearts, I think it'd be cool to ditch the centrally managed monotonic integer and instead have some kind of hashing scheme to keep id-space management simple.

Suppose we have YYYY- {7 most significant bits of sha1(package, date) (increment by one in case of collision)}. I can't be arsed to calc the probability of collision at our volume but I'm going to guess it's rather low. We still have to write the script to check on merge, but by and large anyone can generate an ID and it becomes valid by being accepted into the repo. (I totally get it if people think that's too much of a pain :P)

[JonRowe]

Why not write a script to calculate it and apply as a build step via travis-ci?

[VanessaHenderson]

I feel like this is more important now that OSVDB seems to have been down for the last month or so

[VanessaHenderson]

Yup, so the OSVDB numbering system certainly won't work anymore. They've shut down, see https://blog.osvdb.org/2016/04/05/osvdb-fin/

[postmodern]

@VanessaHenderson opened issue #251 to discuss triaging the OSVDB shutdown.

[mveytsman]

I made a first pass at a rake task to reserve rubysec ids ala @tarcieri's suggestion

If there's consensus I can assign rubysec ids to everything as a step towards getting rid of OSVDB (#251)

It's in #252

[reedloden]

We could also just add support for DWF, which is going to be merged with CVE. We could become our own CNA for DWF. Might be easier.

[phillmv]

So I spent sometime thinking about this. The DWF Reed is referring to is the Distributed Weakness Filing which could use some marketing love if it's to be adopted widely BUT:

If we are to adopt a custom numbering scheme that should be backwards compatible with CVE… we might as well become a numbering authority of this system rather than make our own.

Prompted by #256, barring any objections, in the next few days I'll reserve some address space on DWF and set up a mail forwarder for the domain.