mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #1066] Distinguishing between security patches and non-security patches #6644
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#6644
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Steve-Rithmik on GitHub (Dec 18, 2024).
Original GitHub issue: https://github.com/semver/semver/issues/1066
When dealing with security updates it's quite frustrating having security patches and non-security patches showing up in the same incrementing number.
As a result, there are entire ecosystems of tools out there to monitor your dependencies and tell you when you need to update because one of the patch increments has a security fix. Yes, these tools also help when monitoring a large number of dependencies but even with a small number of dependencies there is no easy way to see when a security patch is available. I find myself largely reliant on these tools to solve the problem of "which releases are security releases".
From the consumer side, there is also a big difference in priority between applying a security patch and a bug fix.
From the developer side, security patches resolving critical or high severity vulnerabilities should never be released along-side functional changes in order to reduce the risk and burden on consumers of the library/api and allow the security fixes to be applied as soon as possible.
As an example, the Grafana project has recently switched to a format that uses +security-## for all security patches in order to increase clarity.
I propose adding to the semver specifications in order to incorporate releases that remove undocumented and/or unintended behavior in the API without changing the specifications of the API (aka, security vulnerabilities).
I can think of multiple solutions:
Major.Minor.Patch.Security where a security fix must be released to all currently supported versions. Subsequent major, minor and patch releases must include the security fix and the security value reset to 0.
Add an optional security identifier similar to specification 9 and 10 that must precede any pre-release or build metadata specification and IS used to denote precedence. Something like 2.3.1!1 (or whatever symbol, I like ! because it's probably an important patch)
Update specification 10 to allow for changes that remove unintended functionality that was never documented or desired and should be treated as higher precedence if it includes the "security" tag
Security patches should be released using the next patch version and use the hyphen pre-release identifier followed by the word "security" to denote a security fix that is available now and will be included in the next patch when it is available. Example, assuming the latest supported versions are 3.0.0 and 2.3.2 the following releases would occur: 3.0.1-security-1, 2.3.3-security-1 which will have lower precedence than 3.0.1 and 2.3.3 when they are released, thus following the existing specifications.
Option 1 seems to easy, I'm guessing there is something I haven't thought of or it will break existing tools that are expecting a 3 part semver.
Option 2 seems less likely to break existing tools, adds an additional symbol to denote security patches, similar to - and + but with higher precedence rather than lower. Down side is that existing symbols to denote pre-release and metadata can be ignored while this symbol would indicate higher precedence and shouldn't be ignored.
Option 3 is easy but there are issues with how precedence should be handled, specification 10 specifically states that anything with a + should be ignored for precedence while specification 9 states that anything with a - has lower precedence than the associated normal version.
Option 4 involves minimal changes to the specification. The precedence is maintained correctly and should work with all existing tools but adding special meaning to part of the identifier following the - is not ideal and a security patch really isn't a pre-release. Existing automation tools will ignore security patches unless configured to deploy pre-release versions.
Anyone have any thoughts on this?
@steveklabnik commented on GitHub (Dec 18, 2024):
We are not going to be making significant changes to the specification, and this would be a big change.
@Steve-Rithmik commented on GitHub (Dec 18, 2024):
@steveklabnik Does this mean there will never be any significant changes to the specification? Since this was closed, I assume that means we're not allowed to talk about things like this here. Is there any venue where discussing big changes to the semver specification is allowed?
I was hoping to have some conversation about this before eventually opening a PR with an RFC and working towards updates to all the tooling as there is no point in doing all that with a half-baked idea and 0 feedback from others.
@ljharb commented on GitHub (Dec 18, 2024):
Either way, a patch is a patch - the way to determine if it's a security patch is the CVE infrastructure, not the version number - whose only job is to communicate breakage. A versioning system that conveys something else would not be semver, it'd be something new.
This would also fail in the almost universal scenario where a patch is fixing a security issue that is not yet public.
@steveklabnik commented on GitHub (Dec 18, 2024):
There is some desire to bring aspects of the specification in line with the various implementations, but it's been very difficult to find any time to do so. (this is also why a lot of issues/PRs should be closed as well, but aren't yet. Trying to catch up a little, which is why I closed this one, but that doesn't mean that the open ones that are similar shouldn't be closed too.) But proposals like "add another digit" are too large as to be out of scope. Plus, this specific topic (both "special accounting for security releases" and "additional numbers that mean something else") have been discussed a number of times over the years, and I'm not aware of any of the various implementations considering adding something like this. Specifications codify existing practice, rather than define new practice.
It's not so much "allowed" vs "not allowed," more of just a "I don't want to lead you on to believe that discussion here is likely to lead to this change happening any time soon."
That said, I didn't realize github discussions weren't turned on for this repository, maybe that would be a fine way to split this difference.
@Steve-Rithmik commented on GitHub (Dec 18, 2024):
Let me know if discussions are turned on, I'd be happy to take this there.
The main reason I am bringing this up is in fact because semver does not match existing practices. Best practice with a security fix is to take your latest supported releases, add the fix, then do a release with the security fix. If you have several bug fixes in development, or even a major/minor release in development, that's all set aside for the security fix which is applied to the last released version.
A versioning system that accounts for security fixes matches existing practices.
The CVE infrastructure is great but not integrated with patch management tools which causes a few issues:
Ultimately, the point of semver is to make management of dependencies easier with a consistent format so the consumer of your API can easily see if this change might contain any breaking changes. Without consideration for security fixes, especially critical fixes, it is hiding that fact that security fixes are available just as a datetime stamp would hide whether there are breaking changes.
Every software ecosystem could benefit from a standard with clear versioning of security patches.
@ljharb commented on GitHub (Dec 19, 2024):
Existing practices do not differentiate between a security fix or any kind of patch, on purpose.