SemVer support for hotfixes/security fixes by third parties #610

New Issue

Closed

opened 2026-02-17 12:15:02 -06:00 by GiteaMirror · 3 comments

GiteaMirror commented 2026-02-17 12:15:02 -06:00

Owner

Copy Link

Originally created by @JasonRShaver on GitHub (Nov 9, 2023).

A common scenario that I run across in my enterprise work around supply chain security and SBOMs is the need for an enterprise to privately fix OSS dependencies (NuGet, NPM, and PyPI packages for example). This may be cases where a security patch needs to be rolled out before coordinated disclosure or an enterprise needs to apply a fix in an OSS dependency before the upstream project releases an update. Another scenario would be for identifying patched dependencies in SBOMs to ensure accurate audit results (VEX may make this easier in the future, but it is not well respected by auditors yet, in my experience).

For a third party consumer, they can't rev the x.y.z number because it will conflict with the next update from the upstream project, and of course any x.y.z-hotfix or x.y.z+hotfix will lose to the clean x.y.z version.

Does the SemVer community have any opinions on third party private fixes/hotpatches? My research indicates this scenario is not supported (e.g., #917), but I'm curious if other stakeholders have proposed extensions to SemVer v2 to enable dependency resolution support for private hotfixes, and/or if the SemVer community itself has an philosophical disagreement with this idea.

An north star vision here might look the NuGet client tool supporting hotfixes when provided by a private upstream registry (Artifactory, Azure Artifacts, etc.), but not enabling the publishing of any hotfixes to the NuGet public registry itself. (Disclaimer: I work for Microsoft, but do not represent the NuGet team or their future plans)

Originally created by @JasonRShaver on GitHub (Nov 9, 2023). A common scenario that I run across in my enterprise work around supply chain security and SBOMs is the need for an enterprise to privately fix OSS dependencies (NuGet, NPM, and PyPI packages for example). This may be cases where a security patch needs to be rolled out before coordinated disclosure or an enterprise needs to apply a fix in an OSS dependency before the upstream project releases an update. Another scenario would be for identifying patched dependencies in SBOMs to ensure accurate audit results (VEX may make this easier in the future, but it is not well respected by auditors yet, in my experience). For a third party consumer, they can't rev the x.y.z number because it will conflict with the next update from the upstream project, and of course any x.y.z-hotfix or x.y.z+hotfix will lose to the clean x.y.z version. **Does the SemVer community have any opinions on third party private fixes/hotpatches?** My research indicates this scenario is not supported (e.g., #917), but I'm curious if other stakeholders have proposed extensions to SemVer v2 to enable dependency resolution support for private hotfixes, and/or if the SemVer community itself has an philosophical disagreement with this idea. An north star vision here might look the NuGet client tool supporting hotfixes when provided by a private upstream registry (Artifactory, Azure Artifacts, etc.), but not enabling the publishing of any hotfixes to the NuGet public registry itself. (Disclaimer: I work for Microsoft, but do not represent the NuGet team or their future plans)

GiteaMirror closed this issue 2026-02-17 12:15:02 -06:00

GiteaMirror commented 2026-02-17 12:15:03 -06:00

Author

Owner

Copy Link

@ljharb commented on GitHub (Nov 9, 2023):

You'd do this with a prerelease of the next patch version, regardless of whether availability was public. There's nothing extra needed here.

@ljharb commented on GitHub (Nov 9, 2023): You'd do this with a prerelease of the next patch version, regardless of whether availability was public. There's nothing extra needed here.

GiteaMirror commented 2026-02-17 12:15:03 -06:00

Author

Owner

Copy Link

@JasonRShaver commented on GitHub (Nov 9, 2023):

Thank you for the quick reply. That's an interesting idea, I'll have to think about if that can address all my scenarios.

Some early thoughts, if you don't mind sharing your opinion/insights:

• If I found 1.0.0 to have a security bug and patched it as 1.0.1-JasonPrivateFix, then the public community releases a 1.0.1-alpha, it would be chosen over the fix. This can be managed in cases where a lock file can be used, but it would be nice if I can say I only want 1.0.0 and any security fixes for it, rather than an alpha which may have fixes for issues other than the security one.
• If I found 1.0.0 to have a security bug and patched it internally as 1.0.1-patched, there is risk of the upstream community creating and publishing their own unrelated instance of 1.0.1-patched which creates package immutability issues (local caches, differing hashes, etc.).

Thanks again for taking the time to respond =)

@JasonRShaver commented on GitHub (Nov 9, 2023): Thank you for the quick reply. That's an interesting idea, I'll have to think about if that can address all my scenarios. Some early thoughts, if you don't mind sharing your opinion/insights: * If I found 1.0.0 to have a security bug and patched it as 1.0.1-JasonPrivateFix, then the public community releases a 1.0.1-alpha, it would be chosen over the fix. This can be managed in cases where a lock file can be used, but it would be nice if I can say I only want 1.0.0 and any security fixes for it, rather than an alpha which may have fixes for issues other than the security one. * If I found 1.0.0 to have a security bug and patched it internally as 1.0.1-patched, there is risk of the upstream community creating and publishing their own unrelated instance of 1.0.1-patched which creates package immutability issues (local caches, differing hashes, etc.). Thanks again for taking the time to respond =)

GiteaMirror commented 2026-02-17 12:15:03 -06:00

Author

Owner

Copy Link

@ljharb commented on GitHub (Nov 9, 2023):

That’s fine, since if the patched version isn’t publicly available, those using it would need to use a specially crafted range to avoid picking up any prereleases but the fixed one.

@ljharb commented on GitHub (Nov 9, 2023): That’s fine, since if the patched version isn’t publicly available, those using it would need to use a specially crafted range to avoid picking up any prereleases but the fixed one.

GiteaMirror referenced this issue 2026-04-16 10:40:44 -05:00

[GH-ISSUE #610] ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ #1297

GiteaMirror referenced this issue 2026-04-20 10:08:43 -05:00

[GH-ISSUE #610] ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ #2164

GiteaMirror referenced this issue 2026-04-25 17:27:17 -05:00

[GH-ISSUE #610] ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ #3146

GiteaMirror referenced this issue 2026-06-13 12:59:54 -05:00

[GH-ISSUE #610] ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ #4675

GiteaMirror referenced this issue 2026-06-15 12:02:39 -05:00

[GH-ISSUE #610] ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ #5548

GiteaMirror referenced this issue 2026-06-17 05:12:20 -05:00

[GH-ISSUE #610] ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ #6421

GiteaMirror referenced this issue 2026-06-20 17:27:40 -05:00

[GH-ISSUE #610] ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ #7405

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

master

isaacs/ranges

docs/README

v2.0.0

v1.0.0-rc.1

v1.0.0

v1.0.0-beta

Labels

Clear labels

bug

consensus seeking

duplicate

extend

layout

pull-request

Mirrored from GitHub Pull Request

question

RFC

spelling/grammar

staled

update

waiting for PR

won't fix

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#610