How to handle gpac?
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 .
Versions present in Debian:
bookworm (and unstable): 2.0.0+dfsg1-2
Open security issues:
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
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
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
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.
Roberto C. Sánchez