Re: How to handle gpac?
Hello,
[looping in the Security team as this involves buster and in general,
their opinion would be very helpful!]
On Thu, Apr 14, 2022 at 8:52 PM Roberto C. Sánchez <roberto@debian.org> wrote:
> Open security issues:
>
> bookworm: 4
> bullseye: 100
> buster: 124
> stretch: 126
Holy smokes! CRAZY!
Let me take a moment here to thank you, genuinely, for dealing with this. \o/
> 1. continue plodding through the vulnerabilities and upstream patches,
> trying to make all the patches work (as noted, this is becoming
> increasingly difficult because the newer fixes are made in code that is
> vastly different from what is present in buster/stretch)
I don't think that's the path we should walk on, really. Backporting
patches of >75 vulnerabilities (assuming few are not-affected, et al)
is an insane amount of work with _maybe_ little benefit? And besides,
what if there's a regression? Finding the root cause and actually
figuring out which patch induced regression would be lethal. And even
if we, let's say, successfully patch the present 125 vulnerabilities,
how long can we sustain this for? There seems to be a huge version gap
b/w stable/sid and buster/stretch, maintaining that for another 2
years is something I wouldn't recommend, really. :)
> 2. drop gpac from stretch LTS support (and buster LTS when it reaches
> that stage)
One good plausible option, for sure. This way users know what to expect, et al.
> 3. update the gpac package in one of the following ways:
>
> 3a. apply fixes to the 100 open issues in the bullseye version
> (1.0.1+dfsg1-4+deb11u1) and then backport that to buster and stretch
> (either now in coordination with the security team, or later once buster
> is LTS); I considered this possibility because the fixes are most likely
> more straightforward to apply given the smaller delta betweeen upstream
> releases involved
I think that still means a lot of work, doesn't it? Just 25
vulnerabilities less but it's still a lot of work and chances of
regression(s) are still (relatively) high. Fixing these 100 CVEs, for
once, would make _some_ sense but then what about 4 years from now,
when bullseye is LTS? Are we going to keep maintaining this as-is? Do
you think it's realistically sustainable for us? :)
> 3b. backport the bookwork version (2.0.0+dfsg1-2) to bullseye, buster,
> and stretch (definitely must be coordinated with the security team)
That looks more reasonable in terms of the effort v/s benefit, but is
it really viable?
$ reverse-depends src:gpac
Reverse-Recommends
* multimedia-animation (for gpac)
* multimedia-devel (for libgpac-dev)
* multimedia-players (for gpac)
* multimedia-video (for gpac)
Reverse-Depends
* ccextractor [amd64 arm64 armhf ppc64el s390x]
* divxenc (for gpac)
* h264enc (for gpac)
* ogmrip [amd64 arm64 armhf ppc64el s390x]
* x264 (for libgpac11)
* xvidenc (for gpac)
How can we ensure that nothing above breaks if we backport the newest
src:gpac to LTS? And also, would it build in the first place? :)
> 4. don't bother with trying to patch all the vulnerabilities
That'd be bad, hehe. I mean, it'd mean that we're accumulating this
huge technical debt for no reason. A much-preferred way would be
either to EOL it and let the users know or actually backport this from
sid.
---
So, in _my_ opinion, my preference would be:
2 (EOL) > 3b (backport from bookworm IFF it's viable and chances of
regression are less) > 3a > 4.
Hope that makes sense? Please let me know if I should be more verbose
in explaining my concerns or thoughts.
> I would very much appreciate feedback/comments/suggestions/etc from
> anyone who would like to contribute to the discussion. I am certain
> that I have missed things, so feel free to point out any gaps in my
> summary/analysis and of course, any suggestions for other possible
> solutions I overlooked would be very much appreciated.
Once again, I'd like to sincerely thank you for your work on this.
It's very much appreciated. \o/
- u
Reply to: