GStreamer 1.22.12 stable release update

[Adam D. Barratt]

I'm part of the team that releases the Debian packages of GStreamer
into Debian. Sebastian had a discussion about a number of stability
and security issues in the GStreamer 1.22.0 version that is currently
in stable.
The agreement with Salvatore was to upload the latest oldstable
release (1.22.12 at the time of writing) to address many of these.
At the moment, all the packages have been prepared in the respective
salsa repositories [1] in the branches `pristine-tar`,
`debian/bookworm` and `upstream-bookworrm [2].
I am new to the process of uploading new stable releases, so looking
into [3], the packages have the version `1.22.12-0+deb12u1` and
`bookworm` in the changelog

I'm afraid I'm a little confused here.

Salvatore is a member of the Security Team, not the Release Team. The
Security Team are obviously free to agree to whatever updates they feel
are appropriate via the security archive, but if you want to update
packages in stable you need to agree that with the Release Team. So far
as I'm aware, this is the first time the suggestion has been raised
with us.

As you referenced the relevant section of DevRef, if the request here
is to update the packages via p-u then please file one release.d.o bug
per source package including all the requested information.

Regards,

Adam

[Salvatore Bonaccorso]

Hi Adam, hi Marc,

Let me try to explain the goal here as it it might get the impression
Adam got confused on seeing this request for the first time.

Post by Adam D. Barratt

I'm part of the team that releases the Debian packages of GStreamer
into Debian. Sebastian had a discussion about a number of stability
and security issues in the GStreamer 1.22.0 version that is currently
in stable.
The agreement with Salvatore was to upload the latest oldstable
release (1.22.12 at the time of writing) to address many of these.
At the moment, all the packages have been prepared in the respective
salsa repositories [1] in the branches `pristine-tar`,
`debian/bookworm` and `upstream-bookworrm [2].
I am new to the process of uploading new stable releases, so looking
into [3], the packages have the version `1.22.12-0+deb12u1` and
`bookworm` in the changelog

I'm afraid I'm a little confused here.
Salvatore is a member of the Security Team, not the Release Team. The
Security Team are obviously free to agree to whatever updates they feel
are appropriate via the security archive, but if you want to update
packages in stable you need to agree that with the Release Team. So far
as I'm aware, this is the first time the suggestion has been raised
with us.
As you referenced the relevant section of DevRef, if the request here
is to update the packages via p-u then please file one release.d.o bug
per source package including all the requested information.

Let me explain a bit how we come here with a request from Marc. While
we were preparing the DSAs for gst-plugins-base1.0 (DSA-5831-1),
gstreamer1.0 (DSA-5832-1) and gst-plugins-good1.0 (DSA-5838-1), the
last one with a relative big set of commits to address the CVEs, I got
in contact with Sebastian, who is both involved in Debian maintenance
but more importantly for this case as well upstream. He pointed out to
us that the 1.22.x series are actually intended to carry those CVE
fixes *and* important bugfixes. The prepared uploads were still good
enough and important to get out that we opted to not respin all but in
that discussion we agreed that it might be a good idea to approach
you, release team and stable release managers to consider doing rbases
to those stable versions for the 1.22.y series in a point release.

Sebastian approached Marc if he is interested to prepare this work.

So this mail serves as proposal for doing so in one of the next point
releases (the next one is too late). We (with my security team hat on)
would strongly support taht we se switch to those following the 1.22.y
branch for the point releases and for upcoming Gstreamer related
security fixes.

In fact the DSA-5838-1 had one backported patch which on top of the
source is correct, but if we would have rebased the version in 1.22.y
we would have fixed as well an bug (not a regression!) in the av1
parser. Notably the version in bookworm misses
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/6d2bc8b8cd6ca8d5ea0f82145a6d52235fdcd631
(again we do not regress here as the issue was present before, but it
ould have been a nice side effect to fix it as well).

Adam does that gives you enough background information on this
request? It was not meant as: hey the security team say we can rebase,
and "bypass" the repsonability of the release team.

Let know please if you need any further information from Marc or
Sebastian on specific 1.22.y questions.

Regards,
Salvatore

[Adam D. Barratt]

Post by Salvatore Bonaccorso
So this mail serves as proposal for doing so in one of the next point
releases (the next one is too late). We (with my security team hat
on) would strongly support taht we se switch to those following the
1.22.y branch for the point releases and for upcoming Gstreamer
related security fixes.

[...]

Post by Salvatore Bonaccorso
Adam does that gives you enough background information on this
request? It was not meant as: hey the security team say we can
rebase, and "bypass" the repsonability of the release team.
Let know please if you need any further information from Marc or
Sebastian on specific 1.22.y questions.

Yes, thanks, and apologies for the knee-jerk reaction to Marc's mail.

In principle the idea sounds good, but particularly to begin with we'd
need to see specifics of the updates. The way that works best for us
for doing that is p-u bugs, as that's the standard workflow we use for
updates via p-u.

Regards,

Adam

[Salvatore Bonaccorso]

Hi Marc,

Post by Adam D. Barratt

Post by Salvatore Bonaccorso
So this mail serves as proposal for doing so in one of the next point
releases (the next one is too late). We (with my security team hat
on) would strongly support taht we se switch to those following the
1.22.y branch for the point releases and for upcoming Gstreamer
related security fixes.

[...]

Post by Salvatore Bonaccorso
Adam does that gives you enough background information on this
request? It was not meant as: hey the security team say we can
rebase, and "bypass" the repsonability of the release team.
Let know please if you need any further information from Marc or
Sebastian on specific 1.22.y questions.

Yes, thanks, and apologies for the knee-jerk reaction to Marc's mail.
In principle the idea sounds good, but particularly to begin with we'd
need to see specifics of the updates. The way that works best for us
for doing that is p-u bugs, as that's the standard workflow we use for
updates via p-u.

I hope you got not 'scarried away' :). Since this is involving new
upstream version inmports/rebases it might be worth of pointing out
that you could filter out the debdiff changes with focusing on the
impact for Debian, so including debian/ changes but filtering e.g. out
autocreated stuff from source.

Does this helps?

Regards,
Salvatore

[Marc Leeman]

No worries, I've been under heavier flack than this.

I prioritised the 1.24.11 release this week and ran into a snag with
my MTU/provider to use reportbug. I'll have a look and if I can not
figure it out, I'll just copy the generated report in gmail.

I informed Sebastian of the slight delay, I'm still on it.

Post by Salvatore Bonaccorso
Hi Marc,

Post by Adam D. Barratt

Post by Salvatore Bonaccorso
So this mail serves as proposal for doing so in one of the next point
releases (the next one is too late). We (with my security team hat
on) would strongly support taht we se switch to those following the
1.22.y branch for the point releases and for upcoming Gstreamer
related security fixes.

[...]

Post by Salvatore Bonaccorso
Adam does that gives you enough background information on this
request? It was not meant as: hey the security team say we can
rebase, and "bypass" the repsonability of the release team.
Let know please if you need any further information from Marc or
Sebastian on specific 1.22.y questions.

Yes, thanks, and apologies for the knee-jerk reaction to Marc's mail.
In principle the idea sounds good, but particularly to begin with we'd
need to see specifics of the updates. The way that works best for us
for doing that is p-u bugs, as that's the standard workflow we use for
updates via p-u.

I hope you got not 'scarried away' :). Since this is involving new
upstream version inmports/rebases it might be worth of pointing out
that you could filter out the debdiff changes with focusing on the
impact for Debian, so including debian/ changes but filtering e.g. out
autocreated stuff from source.
Does this helps?
Regards,
Salvatore

[Marc Leeman]

Post by Salvatore Bonaccorso
I hope you got not 'scarried away' :). Since this is involving new
upstream version inmports/rebases it might be worth of pointing out
that you could filter out the debdiff changes with focusing on the
impact for Debian, so including debian/ changes but filtering e.g. out
autocreated stuff from source.

In any case, the proposed upgrade van 1.22.0 to 1.22.12 is considerable:

1. the affected 'bundles' are gstreamer1.0, gst-plugins-base1.0,
gst-plugins-good1.0 and gst-rtsp-server1.0 (source projects),
inspecting the mono-repo on counting the bugfix commits in the last 2
years:

$ echo $(($(git rev-list --count 1.22.0..1.22.12) - 1))
735

Though they also include fixes for other OSes.

2. Even though the above projects were identified in the mentioned
DSAs, GStreamer does not encourage other components to be of a
different version. In this particular case, this means that the
following components need upgrading too:

gst-plugins-bad1.0 gst-plugins-ugly1.0, gst-libav1.0, gstreamer-vaapi,
gst-python1.0 and gst-editing-service1.0, so the above commits are
split over the 10 source packages.

I just want to make clear that it is not 'a couple of lines' that are changed.

as a reference, in the prepared gstreamer1.0:

$ debdiff gstreamer1.0_1.22.0-2+deb12u1.dsc
gstreamer1.0_1.22.12-0+deb12u1.dsc | wc -l
7085

a considerable part is l10n (changed lines, about 2/3rds).

[Marc Leeman]

Post by Marc Leeman
2. Even though the above projects were identified in the mentioned
DSAs, GStreamer does not encourage other components to be of a
different version. In this particular case, this means that the

I have submitted the first bug report (gstreamer1.0):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092940

Please review before I add the next 9 (to keep the iterations low).