Thanks to those who responded. I will go ahead and start working with the security team on declaring gpac EOL.
Regards, -Roberto On Thu, Apr 14, 2022 at 11:11:52AM -0400, Roberto C. Sánchez wrote: > Hello everyone, > > I've been working on gpac vulnerabilities. The situation has reached a > point where it seemed wise to seek some input from other folks in the > LTS community before continuing. With this message I am specifically > seeking to start a discussion about the best way forward. > > First, some context from the PTS [0]. > > Versions present in Debian: > > bookworm (and unstable): 2.0.0+dfsg1-2 > bullseye: 1.0.1+dfsg1-4+deb11u1 > buster: 0.5.2-426-gc5ad4e4+dfsg5-5 > stretch: 0.5.2-426-gc5ad4e4+dfsg5-3+deb9u1 > > Open security issues: > > bookworm: 4 > bullseye: 100 > buster: 124 > stretch: 126 > > Most of the open vulnerabilities are tagged either <no-dsa> or <ignored> > with the note "Minor issue". If there were only a small handful, it > might make sense to not worry about them. However, given the sheer > number and the fact that new vulnerabilities are being reported > regularly, leaving things as is does not appear to be a sensible choice. > > As the buster and stretch versions are the same I am working on updating > both at the same time (coordinated with the security team). I've > managed to integrate fixes for about 35 of the open CVEs. I've also > been able to identify that several do not actually affect the buster and > stretch versions of gpac. I have also encountered now two issues where > the proof of concept in the upstream GitHub issue produces a failure, > but not the precise one described by the upstream report and > subsequently assigned CVE. It seems likely that there is at least one > significant vulnerability affecting the older buster/stretch gpac that > hasn't been discovered/reported upstream. I have what seems like a > possible fix for that issue, but it isn't entirely clear that it is the > right approach (I would seek assistance from upstream on that particualr > point). > > The other concern that I have is that as I move into the more recently > reported vulnerabilities, which are necessarily fixed in later versions > by upstream, applying the patches becomes progressivley more > challenging. There are still somewhere around 75 vulnerabilities left > to deal with, which is concerning. > > The specific paths forward that I see include: > > ---------------------------------------- > > 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) > > 2. drop gpac from stretch LTS support (and buster LTS when it reaches > that stage) > > 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 > > 3b. backport the bookwork version (2.0.0+dfsg1-2) to bullseye, buster, > and stretch (definitely must be coordinated with the security team) > > 4. don't bother with trying to patch all the vulnerabilities > > ---------------------------------------- > > My concern with trying to continue along the current path (#1) is that > it seems like it will be nearly impossible to properly test this many > patches. Something is bound to break and the amount of testing required > to ensure no breakage or minimal breakage seems very large. > > Dropping support for gpac (#2) or updating (#3) it does have some > additional consequences, as it is not a leaf package. The first package > that would be affected by a significant change to gpac is x264. It has > a build-depends on libgpac-dev and at least one of its binary packages > subsequently depends on the associated libgpac runtime library. > > The second affected package is ccextractor. Starting in bookworm, > ccextractor build depends on libgpac-dev, but its binary package has no > installation dependencies on any gpac binary packages. It would require > a little bit of investigation to determine the specific effect that a > major gpac update would have on it. > > 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. > > Regards, > > -Roberto > > [0] https://tracker.debian.org/pkg/gpac > > -- > Roberto C. Sánchez -- Roberto C. Sánchez
