Re: ccextractor embeds unpatched and vulnerable source code from gpac in buster - 994746
Hi Neil Good summary. Considering the high amount of 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 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 > (Minor issue) unless some kind of code injection also > occurred. So the current list of CVEs in ccextractor are all > (Minor issue). > > Buster isn't LTS yet and Debian security team are not planning a
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
Hi Jeremiah,
On Mon, Sep 06, 2021 at 08:57:04PM -0400, Jeremiah C. Foster wrote:
> > (Jeremiah, shall I explain how to gather this data?)
so there are three very simple scripts involved, which are attached and which
I used to run every Monday and then I massaged them into one email, where I
basically
just resend the same but edited mail every week.
These scripts expect that you have clones of the security-tracker.git repo as
well
as the extented-security-tracker.git repo and the webwml.git repo checked out in
these directories:
~/Projects/security-tracker
~/Projects/extended-security-tracker
~/Projects/debian-www/webwml
I didn't sent that mail yesterday as I planned to send these instructions
instead.
if you have any further questions, please ask.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
„Guten Tag, ich rufe Sie an, um Ihnen mitzuteilen, dass Ihre Tochter seit
geraumer Zeit die schulischen Abläufe erheblich stört.“ - „Entschuldigen Sie,
meine Tochter ist 54 und Ministerin für Schule und Bildung in NRW.“ - „Gut,
dann wissen Sie also, von wem ich rede.“- Germany, early 2021
#!/bin/sh
# WTF licenced, copyright 2019 Holger Levsen
_unclaim(){
TARGET=$1
DIR=$2
figlet $TARGET
cd $DIR
git status
git pull
git status
./bin/review-update-needed --$TARGET --unclaim 1209600 --exclude linux
linux-4.9 linux-4.19 xen
git commit -a -s -m 'semi-automatic unclaim after 2 weeks of inactivity'
git log -p -1
echo
echo "Don't forget to push..."
echo
git status
bash
}
unclaim_lts(){
_unclaim lts ~/Projects/security-tracker
}
unclaim_elts(){
_unclaim elts ~/Projects/extended-security-tracker
}
if [ -z "$1" ] ; then
xterm -e "$0 unclaim_lts" &
xterm -e "$0 unclaim_elts" &
else
$1
fi
#!/bin/bash
# WTF licenced, copyright 2020-2021 Holger Levsen
TRESHOLD=4
cd ~/Projects/security-tracker
git pull
echo
DLANEEDED=~/Projects/security-tracker/data/dla-needed.txt
TMPFILE=$(mktemp)
egrep '^[A-Za-z0-9]+\ \(.*\)' $DLANEEDED | cut -d ' ' -f2-| sort | tr -d
'('|tr -d ')' | sort -u > $TMPFILE
WARNING=$(mktemp)
echo "Current number of package claims in LTS:"
echo ""
( while IFS= read -r LINE ; do
HITS=$(grep -v '^ ' $DLANEEDED | grep -c "$LINE")
PACKAGES=$(grep -v '^ ' $DLANEEDED | grep "$LINE" | cut -d ' ' -f1 |
xargs echo)
echo "$HITS: $LINE"
if [ $HITS -ge $TRESHOLD ] ; then
echo "Warning: $LINE probably claimed too many: $HITS packages:
$PACKAGES" >> $WARNING
fi
done < $TMPFILE ) |sort -nr
echo
if [ -s $WARNING ] ; then
cat $WARNING | sort
else
echo "Nice, noone claimed $TRESHOLD packages or more."
fi
echo
rm $TMPFILE $WARNING
#!/bin/bash
# WTF licenced, copyright 2020 Holger Levsen
cd ~/Projects/security-tracker
git pull
cd ~/Projects/debian-www/webwml
git pull
./english/security/find-missing-advisories --mode DLA --tracker
../../security-tracker/ 2>&1
signature.asc
Description: PGP signature
Re: Lintian changes for LTS development?
On Tue, 28 Sep 2021 11:46:13 +0100 "Chris Lamb" wrote: > Hi Ola, > > > My guess has been that we should not generally fix lintian warnings > > unless they are really important. > > (Agree with this, of course.) > > > So I assume quite a few of them could be removed. But maybe I'm > > wrong here. > > That could work, although it would have the drawback of potentially > hiding the "really important" tags. I suspect we should only consider > removing/hiding tags if they were somehow introduced by the LTS update > process itself. Or, putting it another way: in the usual case, there > should probably be no difference between the Lintian output between > before and after applying a fix for relevant CVE(s)? That was where I was heading too. Lintian doesn't have a comparative mode but I think that's essentially what is needed. Extracting the lintian warnings from the build log or running lintian explicitly against the pre-CVE version and running it again after the build with the final CVE changes. Lintian warnings in tracker.d.o aren't necessarily helpful for this as those were output by lintian in unstable. It should be the appropriate version of lintian for the prospective upload. Maybe a lintian-diff script? - enough fuzzing to handle changes in order in the output, changes in some things like line numbers within the tag messages. We've got debdiff, something like that for lintian would be useful. Nice and simple, return zero on success, print out a diff and exit non-zero on failure. If the script could parse an sbuild pre and post build log file, so much the better. -- Neil Williams = https://linux.codehelp.co.uk/ pgp7gFUcBvQOX.pgp Description: OpenPGP digital signature
Re: Lintian changes for LTS development?
On Mon, Sep 27, 2021 at 04:58:02PM -, Chris Lamb wrote: > Hi, > > Whilst I think of it, are there any changes to Lintian that folks > here might consider particularly useful when doing LTS development? To which lintian? Running stretch lintian tends to give more useful information for packages in stretch than running unstable lintian. > I've already implemented some changes to not emit some specific > warnings when doing security updates, particularly to do with version > numbering. The same problems exist with (old)stable-pu updates, and lintian knowing about differing versioning rules when uploading to anything other than unstable or experimental would be useful. > This is on the basis that if I automatically ignore some of > them, I might be inadvertently 'training' myself to ignore other, > more serious, ones. > > However, I'm sure there is more low-hanging fruit that might prevent > potential regressions. Thoughts welcome. A suppressions list in debian-lts git to be used with --suppress-tags-from-file would be useful. > Regards, cu Adrian
Re: Lintian changes for LTS development?
Hi Ola, > My guess has been that we should not generally fix lintian warnings > unless they are really important. (Agree with this, of course.) > So I assume quite a few of them could be removed. But maybe I'm wrong > here. That could work, although it would have the drawback of potentially hiding the "really important" tags. I suspect we should only consider removing/hiding tags if they were somehow introduced by the LTS update process itself. Or, putting it another way: in the usual case, there should probably be no difference between the Lintian output between before and after applying a fix for relevant CVE(s)? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Re: Lintian changes for LTS development?
Hi Chris and others My guess has been that we should not generally fix lintian warnings unless they are really important. So I assume quite a few of them could be removed. But maybe I'm wrong here. Cheers // Ola On Mon, 27 Sept 2021 at 18:58, Chris Lamb wrote: > Hi, > > Whilst I think of it, are there any changes to Lintian that folks > here might consider particularly useful when doing LTS development? > > I've already implemented some changes to not emit some specific > warnings when doing security updates, particularly to do with version > numbering. This is on the basis that if I automatically ignore some of > them, I might be inadvertently 'training' myself to ignore other, > more serious, ones. > > However, I'm sure there is more low-hanging fruit that might prevent > potential regressions. Thoughts welcome. > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org chris-lamb.co.uk >`- > > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
