Motivation for 1→M und M→1 relationships in Nix security issues #237

New issue

Closed

opened 2024-10-01 15:35:33 +00:00 by erictapen · 1 comment

erictapen commented

2024-10-01 15:35:33 +00:00

(Migrated from github.com)

CVE here means the data behind one CVE ID, so this means that deduplication of our data sources already happened.

Constraints that aren't questioned:

A Nix security issue has always (at least) one CVE
A Nix security issue can have multiple packages

Constraints I would like to discuss:

1→M: One CVE is linked to multiple Nix security issues
Does it actually happen that one CVE not just affects multiple packages (already covered) but actually poses multiple different problems that would be best discussed in separate issues?
M→1: Many CVEs are linked to one Nix security issue
Is this really common or could this be solved by posting references to each other issues or closing one in favor of the other?

Would be interested to hear what you, as future users of the tool, think about this.

Coming from a discussion with @fricklerhandwerk I would like to better understand the reason for the current data model of the Nix security issue. My idea is that by adding some constraints, we could make the data model easier to understand to the user (and easier to implement). CVE here means the data behind one *CVE ID*, so this means that deduplication of our data sources already happened. Constraints that aren't questioned: - A Nix security issue has always (at least) one CVE - A Nix security issue can have multiple packages Constraints I would like to discuss: - **1→M:** One CVE is linked to multiple Nix security issues Does it actually happen that one CVE not just affects multiple packages (already covered) but actually poses multiple different problems that would be best discussed in separate issues? - **M→1:** Many CVEs are linked to one Nix security issue Is this really common or could this be solved by posting references to each other issues or closing one in favor of the other? Would be interested to hear what you, as future users of the tool, think about this.

fricklerhandwerk commented

2024-10-02 08:19:55 +00:00

(Migrated from github.com)

Summary of the discussion with beta testers:

Multiple CVEs could be covered or fixed by one of our records
Multiple records per CVE could happen if we open a new record when an old issue resurfaces
- We can (and probably should) model this as actually re-opening an old record, but that would be the golden path
We have to expect M:M in reality
- Also makes it easier to accommodate for change in requirements

Conclusion: We'll build the UI for CVE:1->M:Issue initially but keep the data model M:M, and extend the UI as needed.

Summary of the discussion with beta testers: - Multiple CVEs could be covered or fixed by one of our records - Multiple records per CVE could happen if we open a new record when an old issue resurfaces - We can (and probably should) model this as actually re-opening an old record, but that would be the golden path - We have to expect M:M in reality - Also makes it easier to accommodate for change in requirements Conclusion: We'll build the UI for CVE:1->M:Issue initially but keep the data model M:M, and extend the UI as needed.

👍 1