[PATCH 0/7] Mark recipes whose point releases are fixes-only (2/3)

[PATCH 0/7] Mark recipes whose point releases are fixes-only (2/3)

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

Second of three series opting recipes into UPSTREAM_STABLE_RELEASE_REGEX. The
first covered recipes whose upstream publishes a written stable-branch policy and
is in master-next. This one covers recipes with no such document, qualifying
instead on branch structure and changelog evidence; the third will cover smaller
components with weaker evidence.

Why
---

The Auto Upgrade Helper's --stable mode proposes upgrades only within a
stable point-release series, so it can be run against a stable branch
without pulling in feature releases. It needs to know, per recipe, which
upstream versions count as a point release, and that is upstream-specific:
for some projects the series is the major, for others major.minor, for
others a suffix that is not dot-separated at all.

upstream-stable-release-point.bbclass derives that regex from PV, and does
nothing until a recipe opts in. This is the enabling work, one recipe at a
time. It matters because point releases are where CVE and crash fixes land,
and counting only bumps since each branch forked, the stable branches have
taken few of them while master takes them routinely.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades

Method
------

Each recipe needed two things: a mechanism that can express its series, and
evidence that point releases in that series carry only fixes.

Screened out before any reading: version schemes that cannot express a point
release, development series (whose point releases are not fixes-only),
abandoned lines, and projects with no per-series branch or other
bugfix-only marker.

Evidence required for the rest:

 - a written upstream policy where one exists, cited by file and line at a
   pinned tag;
 - the changelog for two to three point releases, including at least one
   that is not the newest, with section headings enumerated before any prose
   is read;
 - release dates across series, which show whether the stable branches are
   actually released from: a version published when a strictly higher one
   already exists is a maintenance release by construction;
 - ABI signal where the project provides one, such as libtool version-info
   or a soname;
 - what the OE stable branches have actually done since forking.

A new command-line option, a new configuration option, or a changed
documented default in a point release is disqualifying. An additive API
symbol may be acceptable but is disclosed in the commit message rather than
glossed. Each commit message states what the point releases actually
contain, so the reasoning can be checked rather than taken on trust.

Scope
-----

None of the upstreams in this series publishes a standalone "this branch is
fixes-only" document, so qualification rests on the per-series branch itself
plus the actual changelog content. Each commit message enumerates what recent
point releases contain, along with the mechanism used and any caveat, so the
decision can be checked per recipe.

Where an upstream could not be shown to maintain its stable branches alongside
the current one, the recipe was dropped from this series rather than argued for
on weaker grounds. A per-series branch and a coordinated release history are not
sufficient on their own either: one candidate kept per-minor branches and shipped
its old series for a year alongside the new one, and was still rejected for
adding a configuration option in a point release.

These are collectively higher CVE-exposure recipes than the first series, so
coverage here has practical value even though the evidence is weaker than a
written policy.

Disclosure
----------

Produced with AI assistance, which did the screening, the changelog reading
and the drafting. I have reviewed each recipe myself: the qualification
decision, the evidence cited, and the resulting regex. Errors are mine.

The class exists only on master, hence the /dev/ documentation link and the
target branch.

Daniel Turull (7):
  libxml2: inherit upstream-stable-release-point
  python3: inherit upstream-stable-release-point
  openssl: inherit upstream-stable-release-point
  binutils: inherit upstream-stable-release-point
  libgcrypt: inherit upstream-stable-release-point
  sqlite3: inherit upstream-stable-release-point
  lttng-tools: inherit upstream-stable-release-point

 meta/recipes-connectivity/openssl/openssl_3.5.7.bb | 5 +++++
 meta/recipes-core/libxml/libxml2_2.15.3.bb         | 4 ++++
 meta/recipes-devtools/binutils/binutils.inc        | 5 +++++
 meta/recipes-devtools/python/python3_3.14.6.bb     | 4 ++++
 meta/recipes-kernel/lttng/lttng-tools_2.15.1.bb    | 2 +-
 meta/recipes-support/libgcrypt/libgcrypt_1.12.2.bb | 2 +-
 meta/recipes-support/sqlite/sqlite3.inc            | 2 +-
 7 files changed, 21 insertions(+), 3 deletions(-)

[PATCH 1/7] libxml2: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

libxml2 maintains per-minor stable branches (2.9 through 2.15) that take
only bug-fix micro releases, and releases from several of them in
parallel: 2.13.9 and 2.14.6 went out the same day, after 2.14.5 was
already out. So upgrades within a major.minor are stable point upgrades
per the OE-Core stable release policy (ref-manual, "Stable Point Release
Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://gitlab.gnome.org/GNOME/libxml2/-/tree/2.15

Checked the last three point releases. 2.15.3 (Apr 15 2026) is five
security fixes plus an "Improvements" section that is also entirely fixes,
and 2.15.1 (Oct 16 2025) is security, regression and build fixes. 2.15.2
(Mar 03 2026) is five CVE fixes plus one addition, a --xpath0 option
confined to the xmllint command-line tool.

A public-header diff across the three shows zero added, removed or changed
libxml2.so declarations, so the library API and ABI are unaffected by that
addition.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone picked up 2.9.14, scarthgap 2.12.5 ->
2.12.10.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
---
 meta/recipes-core/libxml/libxml2_2.15.3.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-core/libxml/libxml2_2.15.3.bb b/meta/recipes-core/libxml/libxml2_2.15.3.bb
index 369f27ad2b..8b0ba29412 100644
--- a/meta/recipes-core/libxml/libxml2_2.15.3.bb
+++ b/meta/recipes-core/libxml/libxml2_2.15.3.bb
@@ -31,6 +31,10 @@ BINCONFIG = "${bindir}/xml2-config"
 
 inherit autotools pkgconfig binconfig-disabled ptest
 
+# libxml2 publishes bugfix/security-only micro releases on its per-minor
+# release branches.
+inherit upstream-stable-release-point
+
 LDFLAGS:append:riscv64 = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-lld ptest', ' -fuse-ld=bfd', '', d)}"
 
 RDEPENDS:${PN}-ptest += "locale-base-en-us"

[PATCH 2/7] python3: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

Python maintains each release series on a per-minor maintenance branch
that, once released, takes bug and security fixes only, and it releases
from several at once: 3.10.20, 3.11.15 and 3.12.13 all went out on
2026-03-03, after 3.14.3. So upgrades within a major.minor are stable
point upgrades per the OE-Core stable release policy (ref-manual, "Stable
Point Release Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://devguide.python.org/versions/

Checked the last three point releases by category, since these are
substantial bug-fix releases rather than security-only. 3.14.6 (Jun 10
2026) has 8 Security, 32 Library and 17 Core entries; 3.14.4 (Apr 07 2026)
has 5, 59 and 46. Every C API entry in both is a fix, so neither adds C
API. 3.14.5 (May 10 2026) is mostly fixes but does add RFC 9309 support to
urllib.robotparser -- one extra capability in one module, touching neither
the language, the C API nor the stable ABI.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone 3.10.4 -> 3.10.20, scarthgap 3.12.3 ->
3.12.13, wrynose 3.14.4 -> 3.14.6.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
---
 meta/recipes-devtools/python/python3_3.14.6.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/python/python3_3.14.6.bb b/meta/recipes-devtools/python/python3_3.14.6.bb
index 77333ce3e2..19f4941bac 100644
--- a/meta/recipes-devtools/python/python3_3.14.6.bb
+++ b/meta/recipes-devtools/python/python3_3.14.6.bb
@@ -35,6 +35,10 @@ SRC_URI[sha256sum] = "143b1dddefaec3bd2e21e3b839b34a2b7fb9842272883c576420d605e9
 # exclude pre-releases for both python 2.x and 3.x
 UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P<pver>\d+(\.\d+)+).tar"
 
+# Python publishes bugfix/security-only releases on its per-minor
+# maintenance branches.
+inherit upstream-stable-release-point
+
 CVE_PRODUCT = "python:python python_software_foundation:python cpython"
 
 PYTHON_MAJMIN = "3.14"

[PATCH 3/7] openssl: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

OpenSSL's release strategy states that patch releases contain only bug and
security fixes, with no new features and no API or ABI breaking changes.
It maintains several series at once: 3.0.21, 3.4.6, 3.5.7 and 3.6.3 were
all released on 2026-06-09, with 4.0.0 already out. So upgrades within a
major.minor are stable point upgrades per the OE-Core stable release
policy (ref-manual, "Stable Point Release Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://openssl-library.org/policies/releasestrat/

Checked the last three point releases. Each is labelled "a security patch
release" in its own NEWS.md header, and every entry is a CVE fix, the item
count matching the unique CVE count exactly: 15 CVEs in 3.5.7 (Jun 09
2026), 7 in 3.5.6 (Apr 07 2026), 12 in 3.5.5 (Jan 27 2026).

When a series reaches EOL the regex must be moved to the next maintained
series by hand, as that is a feature-level change.

One limit is worth stating, from this recipe's own history: 3.2.4 -> 3.2.5
was refused on scarthgap in July 2025 for intermittent ptest failures in a
dependent recipe, bisected to an upstream commit and reported upstream,
and the branch went to 3.2.6 instead. A fixes-only release can still fail
to integrate, so proposing an upgrade is not the same as it passing.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone 3.0.2 -> 3.0.19 on the 3.0 LTS series;
scarthgap 3.2.1 -> 3.2.6 then, at EOL, 3.5.5 -> 3.5.7; wrynose picked up
3.5.7.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
---
 meta/recipes-connectivity/openssl/openssl_3.5.7.bb | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-connectivity/openssl/openssl_3.5.7.bb b/meta/recipes-connectivity/openssl/openssl_3.5.7.bb
index 212879dfa3..1f2754d5e0 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.5.7.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.5.7.bb
@@ -24,6 +24,11 @@ SRC_URI[sha256sum] = "a8c0d28a529ca480f9f36cf5792e2cd21984552a3c8e4aa11a24aa31ae
 inherit lib_package multilib_header multilib_script ptest perlnative manpages
 MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
 
+# OpenSSL publishes bugfix/security-only releases on its per-minor branches.
+# When the tracked series reaches EOL, bump the regex manually to the next
+# maintained series.
+inherit upstream-stable-release-point
+
 PACKAGECONFIG ?= ""
 PACKAGECONFIG:class-native = ""
 PACKAGECONFIG:class-nativesdk = ""

[PATCH 4/7] binutils: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

binutils cuts a per-X.Y stable branch, binutils-2_46-branch for the
current series, that takes only bugfixes and backported CVE fixes, and
tags X.Y.Z (Z>0) releases from it. Superseded branches stay alive: one x86
MODRM fix landed on the 2.40, 2.42 and 2.43 branches on the same day in
May 2025. So upgrades within a major.minor are stable point upgrades per
the OE-Core stable release policy (ref-manual, "Stable Point Release
Upgrades"). This is not spelled out in a policy document, so qualification
rests on the branch structure and the release contents below.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/binutils-2_46-branch

Checked the last two point releases. 2.46.1 (Jun 08 2026) is 137 commits,
mostly automatic version-string date bumps, with six substantive changes,
all fixes: gprof testsuite, build warnings, an sframe encoder/decoder
call-site fix, a DOS-filesystem fix and two linker fixes. 2.45.1 (Nov 10
2025) is aarch64/gas fixes to incorrectly restricted instruction
encodings, linker metadata fixes adding GLIBC_ABI_*_TLS version
dependencies to match glibc's own ABI tags, and libctf, strip and warning
fixes. Neither adds options or instruction support.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone has five or more "binutils: stable
2.38 branch update(s)" commits staying within 2.38.x, scarthgap the same
for 2.42.x, and wrynose has already taken 2.46.1.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
---
 meta/recipes-devtools/binutils/binutils.inc | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc
index b3d0728e4b..29c05b1a27 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -15,6 +15,11 @@ DEPENDS = "flex-native bison-native zlib-native gnu-config-native autoconf-nativ
 
 inherit autotools gettext multilib_header pkgconfig texinfo
 
+# binutils maintains a stable branch per X.Y release (e.g. binutils-2_46-branch)
+# that only takes bugfixes and backported CVE fixes; X.Y.Z (Z>0) releases are
+# cut from that branch.
+inherit upstream-stable-release-point
+
 FILES:${PN} = " \
 	${bindir}/${TARGET_PREFIX}* \
 	${libdir}/lib*.so.* \

[PATCH 5/7] libgcrypt: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

libgcrypt keeps a long-lived maintenance branch per minor version,
LIBGCRYPT-1.12-BRANCH matching the current PV with equivalents back to
1.2, and releases from several in parallel: in one week of April 2026 it
released into four of them, 1.12.2 and 1.8.13 on the 15th, 1.11.3 and
1.10.4 on the 21st. So upgrades within a major.minor are stable point
upgrades per the OE-Core stable release policy (ref-manual, "Stable Point
Release Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/gpg/libgcrypt/tree/LIBGCRYPT-1.12-BRANCH

NEWS separates "Bug fixes" from "New and extended interfaces", and neither
point release in the current series has the latter section at all: 1.12.2
(Apr 15 2026) is four fixes, including an ECDH buffer overwrite and a
missing Dilithium bounds check, and 1.12.1 (Feb 20 2026) four build or
arithmetic regressions. 1.12.0 (Jan 29 2026) opens the series and does add
features, confirming X.Y.0 bumps must stay outside the regex.

The libtool version-info in each NEWS heading is upstream's own ABI
record, and across the current series only the revision moves. One
deviation is worth disclosing from the previous series: 1.11.2 adds a
single enum constant, GCRY_KEM_RAW_P256R1, with current and age
incremented together so it stays backward compatible. Point releases here
are fixes-focused rather than absolutely fixes-only, with the deviation
bounded to additive constants.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: scarthgap took 1.10.3 -> 1.10.4, which needed a
build fix backported alongside it because 1.10.4 broke building with -O2
in the sysroot path. kirkstone has taken no in-series bump and stays at
1.9.4.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
---
 meta/recipes-support/libgcrypt/libgcrypt_1.12.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.12.2.bb b/meta/recipes-support/libgcrypt/libgcrypt_1.12.2.bb
index 697deed607..deb053031e 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.12.2.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.12.2.bb
@@ -30,7 +30,7 @@ SRC_URI[sha256sum] = "7ce33c2492221a0436f96a8500215e9f3e3dcb5fd26a757cd415e7a843
 
 BINCONFIG = "${bindir}/libgcrypt-config"
 
-inherit autotools texinfo binconfig-disabled pkgconfig ptest
+inherit autotools texinfo binconfig-disabled pkgconfig ptest upstream-stable-release-point
 
 require recipes-support/gnupg/drop-unknown-suffix.inc
 

[PATCH 6/7] sqlite3: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

SQLite cuts a per-minor maintenance branch for each release series,
branch-3.53 matching the current PV alongside branch-3.52, -3.51 and
-3.50, and tags patch releases off it. Superseded branches keep receiving
them: 3.44.5 and 3.42.1 were released in mid-2025, long after 3.50 was
current. So upgrades within a major.minor are stable point upgrades per
the OE-Core stable release policy (ref-manual, "Stable Point Release
Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/sqlite/sqlite/tree/branch-3.53

Checked the whole current series. 3.53.1 (May 05 2026) through 3.53.4 (Jul
24 2026) are almost entirely memory-safety and corruption-handling fixes:
five out-of-bounds reads, two buffer overreads or overwrites, two integer
overflows, hot-journal rollback with a zeroed super-journal record, safer
double-to-int64 conversion, and mutex acquisition added to a batch of
sqlite3_* entry points. 3.53.0 (Apr 09 2026) opens the series and does add
API surface, confirming X.Y.0 bumps must stay outside the regex.

Two additive exceptions in 3.53.4, neither touching the core library ABI:
the SQLITE_SHELL_EDITION compile-time option for the CLI, and
sqlite3_intck_register() in the incremental integrity-check extension.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone 3.38.2 -> 3.38.3 -> 3.38.5 and
scarthgap 3.45.1 -> 3.45.3. wrynose is at 3.51.3 with no in-series bump
yet.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
---
 meta/recipes-support/sqlite/sqlite3.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/sqlite/sqlite3.inc b/meta/recipes-support/sqlite/sqlite3.inc
index 94dbc38ec5..8791749dc8 100644
--- a/meta/recipes-support/sqlite/sqlite3.inc
+++ b/meta/recipes-support/sqlite/sqlite3.inc
@@ -21,7 +21,7 @@ UPSTREAM_CHECK_REGEX = "releaselog/(?P<pver>(\d+[\.\-_]*)+)\.html"
 
 CVE_PRODUCT = "sqlite"
 
-inherit pkgconfig siteinfo
+inherit pkgconfig siteinfo upstream-stable-release-point
 
 # enable those which are enabled by default in configure
 PACKAGECONFIG ?= "fts4 fts5 rtree dyn_ext"

[PATCH 7/7] lttng-tools: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

lttng-tools maintains a branch per minor series (stable-2.11 through
stable-2.16) and tags point releases from it, releasing from more than one
at a time: 2.14.2 and 2.15.1 went out the same day. So upgrades within a
major.minor are stable point upgrades per the OE-Core stable release
policy (ref-manual, "Stable Point Release Upgrades"). There is no written
policy document, so qualification rests on the branch structure and the
release contents below.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/lttng/lttng-tools/blob/v2.15.1/ChangeLog
  https://github.com/lttng/lttng-tools/tree/stable-2.15

Upstream keeps a ChangeLog with a per-release entry list, and all 48
entries for 2.15.1 (Jun 05 2026, against 2.15.0 in February) are fixes,
tests, documentation or refactors. Seven address machine interface output
alone; the rest cover a consumerd lockfile fd leak across fork+exec, a
missing default kernel probe entry, an uninitialised read in uri_compare,
a musl compatibility fix, popt error handling, test fixes, and one
refactor preparing the CPU-mask escaping fix.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone took 2.13.4 -> 2.13.8 and 2.13.8 ->
2.13.9, scarthgap 2.13.11 -> 2.13.13. wrynose has taken none and sits at
2.14.1.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
---
 meta/recipes-kernel/lttng/lttng-tools_2.15.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.15.1.bb b/meta/recipes-kernel/lttng/lttng-tools_2.15.1.bb
index 9a56d1711b..4623e114ba 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.15.1.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.15.1.bb
@@ -56,7 +56,7 @@ SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
 
 SRC_URI[sha256sum] = "8b6d4ba7ae2c036f7dafbb4e29717677411078f9a9d961b2dc7c1ba16273e9e9"
 
-inherit autotools ptest pkgconfig useradd python3-dir manpages systemd
+inherit autotools ptest pkgconfig useradd python3-dir manpages systemd upstream-stable-release-point
 
 CACHED_CONFIGUREVARS = "PGREP=/usr/bin/pgrep"
 

Re: [ELIN-upstream] [PATCH 0/7] Mark recipes whose point releases are fixes-only (2/3)

[David Partain]

On Tue, 2026-08-04 at 16:11 +0200, daniel.turull@ericsson.com wrote:
> From: Daniel Turull <daniel.turull@ericsson.com>
> 
> Second of three series opting recipes into UPSTREAM_STABLE_RELEASE_REGEX. The
> first covered recipes whose upstream publishes a written stable-branch policy
> and
> is in master-next. This one covers recipes with no such document, qualifying
> instead on branch structure and changelog evidence; the third will cover
> smaller
> components with weaker evidence.

These all look good to me.

David