feat: add go struct definitions of OSV record #333
Conversation
| // | ||
| // See: https://ossf.github.io/osv-schema/#affectedpackage-field | ||
| type Package struct { | ||
| Ecosystem Ecosystem `json:"ecosystem" yaml:"ecosystem"` |
There was a problem hiding this comment.
I'm not sure if using the Ecosystem type is technically correct here. The constants are defined without the :<RELEASE> suffixes that ecosystems use
(e.g. EcosystemAlpine Ecosystem = "Alpine", but this would hold Alpine:v3.16)
There was a problem hiding this comment.
Ecosystem should just be string here I believe. On osv-scanner's side we have the Parsed type, but that's not available in osv-schema (since it requires some opinionated decisions.)
There was a problem hiding this comment.
okay, I've made it a string
Signed-off-by: Michael Kedar <[email protected]>
michaelkedar
force-pushed
the
go-structs
branch
from
28b7dc0 to
7c21232
Compare
Signed-off-by: Michael Kedar <[email protected]>
|
|
||
| // MarshalJSON implements the json.Marshaler interface. | ||
| // | ||
| // This method ensures times all times are formatted correctly according to the schema. |
There was a problem hiding this comment.
Correct comment grammar
| // This method ensures times all times are formatted correctly according to the schema. | |
| // This method ensures all times are formatted correctly according to the schema. |
| "time" | ||
| ) | ||
|
|
||
| // Package identifies the affected code library or command provided by the |
There was a problem hiding this comment.
Standardize on the verb for consistency
| // Package identifies the affected code library or command provided by the | |
| // Package describes the affected code library or command provided by the |
| DatabaseSpecific map[string]interface{} `json:"database_specific,omitempty" yaml:"database_specific,omitempty"` | ||
| } | ||
|
|
||
| // Severity is used to describe the severity of a vulnerability for an affected |
There was a problem hiding this comment.
Standardize for consistency.
| // Severity is used to describe the severity of a vulnerability for an affected | |
| // Severity describes the severity of a vulnerability for an affected |
|
|
||
| // MarshalJSON implements the json.Marshaler interface. | ||
| // | ||
| // This method ensures Package is only present if it is not equal to the zero value. |
There was a problem hiding this comment.
Is it possible to also implicitly meet or explicitly enforce the need for an introduced event here? https://ossf.github.io/osv-schema/#requirements
I'm leaning towards implicitly adding a zero value in the absence of an explicit one over failing when one's absent, for user-friendliness, even though I'm normally very anti implicit behaviours. I'm not seeing any immediate downside from this approach...
|
|
||
| // MarshalYAML implements the yaml.Marshaler interface. | ||
| // | ||
| // This method ensures times all times are formatted correctly. |
There was a problem hiding this comment.
Make consistent with MarshalJSON()
| // This method ensures times all times are formatted correctly. | |
| // This method ensures times all times are formatted correctly according to the schema. |
| // and so on about the vulnerability itself. | ||
| // | ||
| // See: https://ossf.github.io/osv-schema/#references-field | ||
| type Reference struct { |
There was a problem hiding this comment.
Could we consolidate all of the types before the funcs, for readability?
| // in the life cycle of a vulnerability. | ||
| // | ||
| // See: https://ossf.github.io/osv-schema/#credits-fields | ||
| type Credit struct { |
There was a problem hiding this comment.
Could we consolidate all of the types before the funcs?
| URL string `json:"url" yaml:"url"` | ||
| } | ||
|
|
||
| // Credit gives credit for the discovery, confirmation, patch, or other events |
There was a problem hiding this comment.
Standardize for consistency.
| // Credit gives credit for the discovery, confirmation, patch, or other events | |
| // Credit describes who to give credit to for the discovery, confirmation, patch, or other events |
Moving the struct definitions of the OSV record from osv-scanner to this repository, since it makes more sense to live in the
osvschemamodule.I've also added the new
upstreamfield to the struct. It's probably worth having a discussion on how to make sure these structs remain in-sync with any future changes to the schema.