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

Version SECURITY.md #1871

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+3 −3
Open

Version SECURITY.md #1871

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
6 changes: 3 additions & 3 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,11 +67,11 @@ security vulnerabilities.
| Version / branch | Supported |
| --------- | ---------------------------------------------------- |
| main | :white_check_mark: :construction: ALL fixes immediately, but this is a branch under development with a frequently unstable ABI and occasionally unstable API. |
| 3.2.x | :white_check_mark: All fixes that can be backported without breaking ABI compatibility. |
| 3.3.x | :white_check_mark: All fixes that can be backported without breaking ABI compatibility. |
| 3.2.x | :warning: Only the most critical fixes, only if they can be easily backported. |
| 3.1.x | :warning: Only the most critical fixes, only if they can be easily backported. |
| 3.0.x | :warning: Only the most critical fixes, only if they can be easily backported. |
Comment on lines 72 to 73
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this true? Are we willing to still backport as far back as 3.0?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think fixes should be released all the way back to 2.5.x if it is a critical security issue with a published CVE, since that advertises that a vulnerability exists. I would assume there's software that can't switch to 3.x due to the API changes, so needs a 2.5.x fix. In that case, patch releases are usually only when specially requested by someone who needs them.

There is very little testing of old releases, so a bug that's only present in 3.2 or earlier may never be found. (That limitation might be worth mentioning in the Testing section of this document too.)

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree in principle but wonder if in practical terms, we are able to maintain 2.5.x to the historic level of quality, ie fuzz testing and everything else? It seems like a fix to 2.x might require a lot of someone's time, if we've stood down all the CI, and standing up the CI again also sounds like a lot of work?

| 2.5.x | :warning: Only the most critical fixes, only if they can be easily backported. |
| <= 1.x | :x: No longer receiving patches of any kind. |
| <= 2.x | :x: No longer receiving patches of any kind. |

## Signed Releases

Expand Down