Re: How to handle gpac?
Hi Roberto,
I agree with Utkarsh basically. Fixing over 100 (or even over 20)
issues through patches drastically increases chances to make a
mistake. Backporting newer version also has downsides.
I would propose to declare it as EOL.
Best regards
Anton
Am Do., 14. Apr. 2022 um 17:22 Uhr schrieb Roberto C. Sánchez
<roberto@debian.org>:
>
> 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
>
Reply to: