Add last_affected event type.
#38
Conversation
Part of #35.
oliverchang
force-pushed
the
last_affected
branch
from
335ab3c
to
3a9459d
Compare
| } | ||
| }, | ||
| "required": [ | ||
| "last_affected" |
There was a problem hiding this comment.
Should we also add validation to assert that a fixed event cannot occur alongside a last_effected event and vice versa?
There was a problem hiding this comment.
Thanks, that's a good idea! I'll look at doing this.
That said, I'm wondering how this would look like for GHSA specifically when an entry wants to encode both <= and < (the patched version)? Would you just be using "fixed" here to capture the < and then database_specific to capture the <= ?
There was a problem hiding this comment.
Currently if an advisory has a fix we replace the upper bound with < f.i.x when we rehydrate and consider it an acceptable change. It's only for advisories that don't have a fix that we need to add the rehydration hints.
There was a problem hiding this comment.
And same thing for the other direction when transforming to OSV - if an advisory has a fix, we add the fixed event and don't add the rehydration hint.
There was a problem hiding this comment.
Thanks for clarifying!
There was a problem hiding this comment.
Also added the JSON validation.
Co-authored-by: Chris Bloom <[email protected]>
* Add `last_affected` event type. (#38) * Add `last_affected` event type. Part of #35. * Update docs/schema.md Co-authored-by: Chris Bloom <[email protected]> * JSON validation Co-authored-by: Chris Bloom <[email protected]> * Add database_specific to `affected[].ranges[]`. (#37) * Add database_specific to `affected[].ranges[]`. This is intended only for metadata that enables databases to losslessly convert OSV entries back into their original representation. Part of #35. * Update docs/schema.md Co-authored-by: Chris Bloom <[email protected]> Co-authored-by: Chris Bloom <[email protected]> * Bump version and add change log. Co-authored-by: Chris Bloom <[email protected]>
Part of #35.