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
