Hi Neil Good summary.
Considering the high amount of <no-dsa> marked CVEs for ccextractor I think the best way forward is to keep the same track. We mark the CVEs as no-dsa if they are marked as no-dsa for later releases. It also follows the debian security team track. If we have issues in gpac that are not investigated further, it is worth the effort to do so. But do not be shy about marking them as no-dsa. That can typically be done easily by looking merely on the description. They should be rather serious to warrant a fix. I'm not sure we should "ignore" the issues. I have been of that opinion in the past but I have learnt that we generally mark them as no-dsa instead, unless there is a strong reason to not fix it. Best regards // Ola On Mon, 27 Sept 2021 at 15:04, Neil Williams <codeh...@debian.org> wrote: > Background > ========== > > https://tracker.debian.org/pkg/gpac > 48 security issues in stretch > 14 security issues in sid > 47 security issues in buster > 15 security issues in bullseye > 14 security issues in bookworm > > https://tracker.debian.org/pkg/ccextractor > 23 low-priority security issues in buster > 23 low-priority security issues in bullseye > > ccextractor versions: > oldstable: 0.87+ds1-1 > stable: 0.88+ds1-1 > testing: 0.93+ds2-1 > unstable: 0.93+ds2-1 > > #994746 clones #994754 for the versions of ccextractor in buster and > bullseye: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994746 > "ccextractor embeds unpatched and vulnerable source code from gpac" > > The bug has been fixed in unstable by repacking the orig.tar.gz as > +ds2 and using the system gpac. This change has migrated into bookworm. > > Bullseye is fixable using a simple backport of ccextractor 0.932+ds2-1 > to bullseye, using the libgpac10 which is already in bullseye at version > 1.0.1+dfsg1-4+deb11u1. So this would create a 0.93+ds2-1~bpo11+1 > version of ccextractor in bullseye-backports, with all CVEs handled via > the system libgpac10 with a quick change in the security tracker CVE > list. > > There was a version of ccextractor in Stretch (0.86+ds1) but the > specific problem is usage of ccextractor in buster. > > Problems in buster > ================== > > 1. ccextractor only embeds some of the source code from gpac - the > command line gpac code is not embedded and some of the code which goes > into libgpac10 is also not embedded. gpac upstream have changed the mix > of which files go into libgpac10 and which go into an application > at each relevant version: 0.5.2, 0.7.1 and 1.0.1. > > 2. ccextractor prior to 0.9.3 embeds gpac 0.7.2-DEV (the 0.7.1 gpac > git tag and a few small changes). 0.7.1 was packaged for Debian but > never made it into any stable release. Bullseye has a newer system > gpac (same as bookworm & sid), buster and stretch have an older system > gpac (0.5.2 with some changes). > > 3. ccextactor upstream embeds gpac using an AppWizard which collapses > and changes the *path* to the affected source code files, so patches > have to be manually ported from gpac to ccextractor as well as coping > with the different versions of gpac between the system and the > embedded code. e.g. src/isomedia/box_code_base.c becomes > src/gpacmp4/box_code_base .cand src/odf/odf_code.c becomes > src/gpacmp4/odf_code.c > > 4. ccextractor from buster (0.87, embedding gpac 0.7.1) *does not > compile* against the libgpac-dev from either bullseye (1.0.1) or buster > (0.5.2). ccextractor upstream fixed their code to use gpac 1.0.1 only > in 0.9.3. > > 5. Uploading gpac 0.7.1 from snapshots would be disruptive to other > reverse dependencies of gpac and doesn't solve the problem of porting > patches to multiple versions of gpac. > > CVEs in ccextractor > =================== > > A CVE in gpac is not necessarily a CVE in ccextractor - some source > code is simply missing. What source code does exist is mostly reachable > from the ccextractor command line, given a suitable input file. > ccextractor upstream tests use multiple input files, each typically 3G > in size. > > Every new CVE against gpac (and there are a LOT) would need to be > checked twice: > > a) follow the CVE link to the upstream gpac git & locate the vulnerable > file(s) > > b) Correlate those with the same filenames in a different path > within the embedded ccextractor source code (that part could be > scripted) > > c) If present, download the upstream test case & attempt to > reproduce against ccextractor > > d) update the security tracker > > e) manually port the upstream commit to the different paths used in > ccextractor and adjust the patch for changes between upstream 1.0.1 > and embedded 0.7.1 (having already done the port of the change from > 1.0.1 to 0.5.2 for the system gpac). > > The security team have said that all CVEs against ccextractor would be > <no-dsa> (Minor issue) unless some kind of code injection also > occurred. So the current list of CVEs in ccextractor are all <no-dsa> > (Minor issue). > > Buster isn't LTS yet and Debian security team are not planning a DSA > for ccextractor in buster, so there is no immediate rush. > > I have reproduced a few ccextractor crashes using upstream test files > linked from gpac CVEs using the version of ccextractor in buster. > > Possible solutions > ================== > > A: Add a permanent lump of manual work for every CVE reported against > gpac and, once buster is LTS, make uploads for two source packages at > different versions and with patches that cannot be imported between the > two without manual changes. > > B: Downgrade customer functionality in ccextractor for buster and > stretch to the system gpac and therefore reduce the workload by half. > As noted above, ccextractor does not, yet, compile using that version > of system gpac. > > C: ignore all newly reported CVEs for ccextractor in buster, only > handle gpac and leave ccextractor vulnerable to (i.e. seg fault) at > least some of the known and new CVEs in gpac. > > So far, opinion (Sebastien, Raphael & I) is all for option C: - leave > ccextractor unchanged in buster. > > Have I missed another solution? Does anyone object to adopting solution > C:? > > > -- > Neil Williams > ============= > https://linux.codehelp.co.uk/ > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
