On Mon, 31 Aug 2009 03:09:02 +0200 Nico Golde wrote: > Hi, > * Michael S Gilbert <[email protected]> [2009-08-31 02:29]: > > On Mon, 31 Aug 2009 00:23:00 +0200 Nico Golde wrote: > > > > > * Michael Gilbert <[email protected]> [2009-08-30 19:06]: > > > > Author: gilbert-guest > > > > Date: 2009-08-30 17:09:16 +0000 (Sun, 30 Aug 2009) > > > > New Revision: 12708 > > > > > > > > Modified: > > > > data/CVE/list > > > > Log: > > > > beginning of embedded code copies triage (5 down 395 to go) > > > > > > > > Modified: data/CVE/list > > > > =================================================================== > > > > --- data/CVE/list 2009-08-30 03:00:07 UTC (rev 12707) > > > > +++ data/CVE/list 2009-08-30 17:09:16 UTC (rev 12708) > > > > @@ -1286,6 +1286,7 @@ > > > > CVE-2009-2660 (Multiple integer overflows in CamlImages 2.2 might > > > > allow ...) > > > > {DSA-1857-1} > > > > - camlimages 1:3.0.1-3 (medium; bug #540146) > > > > + - advi <not-affected> (affected code section not present in > > > > advi code copy of camlimages) > > > > CVE-2009-2657 (nilfs-utils before 2.0.14 installs multiple programs > > > > with unnecessary ...) > > > > - nilfs2-tools <not-affected> (dh_fixperms removes the setuid > > > > and setgid bits from all files) > > > > CVE-2009-2656 (Unspecified vulnerability in the com.android.phone > > > > process in Android ...) > > > > @@ -1303,6 +1304,8 @@ > > > > CVE-2009-XXXX [VLC: integer underflow in Real RTSP] > > > > - vlc 1.0.1-1 > > > > - mplayer <unfixed> > > > > + - xine-lib <unfixed> > > > > + NOTE: affected mplayer code copy present in xine-lib > > > > > > Did you only check if the code is present or also if it's > > > used? > > > > yes, i only checked that the embedded code is present. after further > > review of the full disclosure posting, it is clear that xine-lib is not > > affected because it has additional an additional check. > > I wasn't talking about this issue in specific, just noticed > it in this commit. If you didn't do that yet please do so to > avoid lots of false-positives and someone needs to do the > work anyway.
if the affected code is present, isn't it almost always the case that it is actually used? the only situation where this isn't the case (that i can think of right now) is dead code, which the maintainer should probably be working with upstream to remove anyway. would it be ok for me to add a 'TODO: <x> code copy present, check whether it is used' when i find that the code copy is in the package? figuring out whether the affected code is present in these 400 instances is already quite an undertaking, and it will be significantly more work to parse all the make files to determine if that code gets built and gets called from somewhere. i would hope others may be willing/able to help out at that point? mike _______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
