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 <robe...@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
