Ensure security bugs always have a tag attached

When a CVE is announced, and committed to stable branches without a tagged release it creates automation problems.

Severity or classification of CVE does not matter. This should apply to all security issues, regardless of their severity or classification.

CVE databases in various scanners have to either declare that there is no known version of software that contains the fix. Or they have to declare a next/future/non-existent version as the one containing the fix. This can cause issues as users demand upgrades to OpenSSL of a version that does not exist.

Other projects always use semver versions and always tag releases containing a security fix. Doing so could help OpenSSL project, especially if it is done on lightweight basis without "full" point release machinery.

If CVE gets announced together with a point release - things are great, as there are correct references everywhere w.r.t. versions of software that have the fix.

CVE-2025-4575 was announced on 22nd of May 2025 without being tagged. A 3.5.1 release came out July 1st. During that time between 22nd of May 2025 until July 1st, a lot of manual things had to happen, which could have been avoided with a nano tag. Specifically individual distributions had to cherry-pick patches; create advisories; publish advisories; ensure security scanners pick up the advisories; and then eventually all of that work was thrown away once 3.5.1 was released and upgraded to.

Here is a proposal for an alternative approach:

1. If CVE is disclosed, and stable branches are not ready for release

2. Pick the last released tag. In above example for CVE-2025-4575 that would be 3.5.0.

3. Apply security fixes to 3.5.0, ideally conflict free - for example without updating CHANGES.md NEWS.md openssl version string. OR ensure that updates to such volatile files are done in separate commits. This is to ensure that cherry-picking patches to different branch points is as easy as possible for distributions.

4. Create a micro-tag of such security-only bugfix. In this example 3.5.0.1.

5. Merge 3.5.0.1 into stable branch

6. Publish CVE disclosure mentioning that CVE is fixed in 3.5.0.1

Above achieves multiple goals:

• distributions/packagers that can upgrade, can perform git checkout a tag and build from it; or download github autogenerated tarball and build from it

• automation to upgrade package in all distributions just works (debian uscan, fedora release monitoring, etc)

• those that need to cherry-pick patches, can do so with automatic git cherry-pick most of the time, as files that cause conflicts are in separate commits (updates to CHANGES.md NEWS.md, openssl version string).

• those tracking snapshots of the stable branches, know the difference with git describe if they are before/after 3.5.0.1 barrier, as git describe counting number of commits resets

Note that the goals are to ensure there is a tag for a disclosed CVE always, to always have semver compatible reference to version numbers that contain a fix.

One can achieve the above goal in different ways too. For example to avoid introducing nano-versions, one can also do:

• branch of the first commit after last tag 3.5.0, that bumps version number

• apply security patches, tag normal 3.5.1, add commit that bumps dev version to 3.5.2

• merge that into stable branch upon disclosure

• such that 3.5.1 security release only has security fixes, without the rest of stable updates not yet ready for release, and stable branch gains 3.5.1 tag and effectively moves all outstanding changes to be released as part of 3.5.2

Another alternative, is to simply always cut a point release when CVE happens, irrespective of the CVE severity or impact analysis.

Examples of projects that ensure all CVE fixes have tagged releases are:

• golang

• x/net

• x/crypto

They always tag a release, and it is either security-only fixes; or a regular non-security point release.

Thus golang never has this situation - "You can find fixes in these git commit hashes, good luck cherry-picking those - or well be vulnerable for multiple weeks until a stable point release is actually made".

Note, this is a request/proposal, but I have no stake in the game, as I do not handle publication of OpenSSL CVEs, but I am consuming them. If tags are created for CVE fixes, it would help automatically ingesting and upgrading OpenSSL in all the distributions as most have automation to handle upgrades of software versions.