5.2.0 #464
Merged
5.2.0 #464
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Creating README for bundled file creation
Fixes Issue #265
Fix schema errors reported in #272. This will need to be tested by running a new schema bundle.
Updates urls and fixes #274. Also updated rules reference as the numbering has changed since the original reference was defined.
Add additionalProperties equal to false for the product object in the base schema. This resolves Issue #259.
Add additionalProperties equal to false for the product object in the bundled schema. This resolves Issue #259.
Add additionalProperties equal to false for the product object in the bundled schema. This resolves Issue #259.
Add additionalProperties equal to false for the product object in the bundled schema. This resolves Issue #259.
Add additionalProperties equal to false for the product object in the bundled schema. This resolves Issue #259.
Add additionalProperties equal to false for the product object
Document CVD ID format in CVE_Record_Format.json
Change master->main branch references in validate-schema.yml. This fixes Issue #326.
Change master->main branch references in validate-schema.yml
… 4.0 Updated rejected example CVE Record to include a better rejectedReasons value. Fixes Issue #313
Rejected example CVE Record is inconsistent with 4.5.3.7 in CNA Rules…
Removed old comment about non-".json" that doesn't apply to the purpose of the code. Fixes Issue #307
Remove unneeded comment in validate-schema.yml
The CVE Record Format legacy naming was used in a few places in the mindmap file. Updated to use the correct naming. This fixes Issue #305
Updated naming for CVE Record Format index.js mindmap
Adding an example of using a tag at the container level. Implements suggestion in Issue #277
Adding an example of using a tag at the container level. Implements suggestion in Issue #277
Include tag property example for advanced record examples
Fix typo in test readme
This clarifies the procedures around updating the RFD number in an RFD pull request after approval of an RFD by the CVE Board. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
At Matt Powers' recommendation, this amends the "Compatibility and Migration" section of the RFD template to describe expectations for analyzing and planning migrations more clearly, including specific questions which ought to be answered, and clarifying the limits of SchemaVer in expressing the adoption burden of new features. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
This rewrites the core content of the RFD to base the proposed new fields on the `affected` array instead of basing them on the `cpeApplicability` object as the prior version of the RFD did. The motivation and outcomes are generally unchanged, but the specifics of the proposed edits are now different. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
This amends the specification for Package URLs to no longer permit versions in them, updating the description and examples for the `packageURL` field of the `product` object. The actual enforcement of this requirement will need to be done within CVE Services. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
Based on conversations with Matt Power, I've amended the text of the "Compatibility and Migration" section of the RFD template in a couple of ways: 1. Removed explicit reference to SchemaVer as the versioning scheme of choice for the CVE Record Format. 2. Introduced a set of questions which must specifically be answered in any submitted RFD. The key goal here is to balance the need for a high level of rigor around compatibility and migration in CVE because it is a systemically-important and large multi-stakeholder system with the need to not be overly prescriptive in the RFD template in ways which may in fact reduce rigor by over-specializing RFD requirements on today's considerations for what the important questions are. The questions included are specific, and intended to capture key concerns about forward compatibility and the impact of changes on CVE consumers particularly. Separately, references to SchemaVer were removed because, while it is my understanding that SchemaVer is the version scheme of choice for the CVE Record Format, that is not currently codified and itself likely ought to go through an RFD process to firmly resolve. In fact, Matt Power has raised concerns that SchemaVer may be insufficiently expressive for the versioning constraints under which CVE operates, and I'd rather not attempt to resolve that question in the context of this process-focused RFD. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
Amend the definitions of "backward compatibility" and "forward compatibility" in the "Compatibility and Migration" section of the RFD template to more clearly explain requirements for RFD writers. In the future we'd like this section to be more rigorous, and ideally to provide a detailed breakdown of what kinds of changes in the schema are considered "breaking," but the versioning rules for the CVE Record Format aren't sufficiently defined yet. I recommend developing an RFD to solidify the versioning rules, and then amending the template to require greater rigor around compatibility in this section. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
Co-authored-by: Jon <darakian@github.com>
Co-authored-by: Andrew Pollock <andrewpollock@users.noreply.github.com>
Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
Per the RFD rules, assign ID #1 to the first RFD. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
RFD to introduce an RFD process
Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
Per discussion in the QWG, this amends the RFD to clarify that the new identifier fields being proposed are not able to fulfill the "identifier-like" requirement in the `product` object inside the `affected` array. While this may be changed in the future, for today it is the easiest path forward for CVE data consumers, who could adopt the new fields if _desirable_ but would not be obligated to do so. Signed-off-by: Andrew Lilley Brinker <alilleybrinker@gmail.com>
After feedback from the CVE Board, this RFD is being split into two, with this part covering *only* the addition of support for Package URLs, and the other part (to be opened as a separate RFD) covering support for OmniBOR Artifact IDs. This commit does the split, and makes no edits besides removing the OmniBOR pieces and smoothing out the remaining language where necessary. Signed-off-by: Andrew Lilley Brinker <alilleybrinker@gmail.com> feat: ensure new IDs can't fulfill "identifier-like" requirement Per discussion in the QWG, this amends the RFD to clarify that the new identifier fields being proposed are not able to fulfill the "identifier-like" requirement in the `product` object inside the `affected` array. While this may be changed in the future, for today it is the easiest path forward for CVE data consumers, who could adopt the new fields if _desirable_ but would not be obligated to do so. Signed-off-by: Andrew Lilley Brinker <alilleybrinker@gmail.com>
Since this RFD is now Package URL specific, this renames the RFD file to reflect the new title. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
…d-rfd RFD: Support for Package URLs
…urls Add `packageURL` field to product in `affected` array.
adding new bundled files for 5.2.0 release
update dataVersion to 5.2.0
update dataVersion to 5.2.0
update dataVersion to 5.2.0
update dataVersion to 5.2.0
update dataVersion to 5.2.0
update dataVersion to 5.2
update dataVersion to 5.2.0
ccoffin
added a commit
that referenced
this pull request
Oct 29, 2025
Merge pull request #464 from CVEProject/5.2.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merging final 5.2.0 release into the main branch