Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add clarity around distros' use of aliases #250

Merged
merged 3 commits into from
Jul 22, 2024
Merged

add clarity around distros' use of aliases #250

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3939ea9
add clarity around distros' use of aliases
luhring Jul 10, 2024
f84a635
reword sentence about patching aliases
luhring Jul 11, 2024
21cbf35
merge paragraphs on distro use of aliases
luhring Jul 11, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 12 additions & 6 deletions docs/schema.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -460,11 +460,11 @@ databases, in the form of the `id` field. This allows one database to claim that
its own entry describes the same vulnerability as one or more entries in other
databases.

Two vulnerabilities can be described as aliases if a potential patch that
addresses one of the vulnerabilities (and no other vulnerabilities) will also
address the other vulnerability, and vice versa. Aliases may be used for
vulnerabilities affecting different packages or ecosystems as long as they
follow this definition.
Two vulnerabilities can be described as aliases if they affect any given
software component the same way: either both vulnerabilities affect the software
component or neither do. And, consequently, a potential patch that addresses one
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grammar nit: don't start sentences with a conjunction.

Suggested change
component or neither do. And, consequently, a potential patch that addresses one
component or neither do. Consequently, a potential patch that addresses one

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or more invasively,

"A subsequent patch addresses both of the vulnerabilities (and no others), and vice versa."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adjusted in f84a635

of the vulnerabilities (and no other vulnerabilities) will also address the
other vulnerability, and vice versa.

Aliases should be considered symmetric (if A is an alias of B, then B is an
alias of A) and transitive (If A aliases B and B aliases C, then A aliases C).
Expand All @@ -475,6 +475,13 @@ vulnerabilities as `aliases` would mean that they are all identical (due to the
symmetry/transitivity of `aliases`), not that one release fixes multiple
(distinct) vulnerabilities.

Aliases should **not** be used to refer to vulnerabilities in packages upstream
oliverchang marked this conversation as resolved.
Show resolved Hide resolved
or downstream in a software supply chain from the given OSV record's affected
package(s). For example, if a CVE describes a vulnerability in a language
library, and a Linux distribution package contains that library and therefore
publishes an advisory, the distribution's OSV record must not list the CVE ID as
an alias. (It should use the `related` field instead.)

## related field

```json
Expand Down Expand Up @@ -1613,4 +1620,3 @@ When a package in the `Android` ecosystem is the Linux kernel source code, its `
- NVIDIA
- Qualcomm
- Unisoc