Author: gilbert-guest Date: 2009-08-24 00:59:44 +0000 (Mon, 24 Aug 2009) New Revision: 12668 Added: bin/inject-embedded-code-copies Modified: data/embedded-code-copies Log: introduction of inject-embedded-code-copies Added: bin/inject-embedded-code-copies ==================================================================--- bin/inject-embedded-code-copies (rev 0) +++ bin/inject-embedded-code-copies 2009-08-24 00:59:44 UTC (rev 12668) @@ -0,0 +1,112 @@ +#!/usr/bin/python + +import os +import sys +import tempfile + +if ( len( sys.argv ) != 3 ): + sys.stderr.write( ''usage: %s <embedded code copies file> <cve list>\n'' % sys.argv[0] ) + sys.exit( 1 ) + +todo_note = ''\tTODO: check embedded %s code copy [- %s %s]'' +todo_note2 = ''\tTODO: check original source code [- %s <unfixed>]; embedded by %s'' +fname_embed = sys.argv[1] +fname_cve = sys.argv[2] + +if not os.path.exists( fname_embed ): + sys.stderr.write( ''error: embedded code copies file \''%s\'' does not exist.\n'' % fname_embed ) + sys.exit( 1 ) + +if not os.path.exists( fname_cve ): + sys.stderr.write( ''error: cve list file \''%s\'' does not exist.\n'' % fname_cve ) + sys.exit( 1 ) + +origlist = [] +embedlist = [] +typelist = [] +nembeds = 0 +found_begin = False +fembed = open( fname_embed , ''r'' ) +line = fembed.readline() +while line: + if found_begin: + if not ( line.startswith( ''\t'' ) or line.startswith( '' '' ) or line.startswith( ''\n'' ) ): + orig = line.split( '' '' )[0].strip( '':\n'' ) + elif line.lstrip( '' \t'' ).startswith( ''-'' ): + split = line.split( '' '' ) + embedder = split[1].strip( '':'' ) + type = split[2].strip( ''\n'' ) + if ( len( embedder ) != 0 ) and type in [ ''<unfixed>'' , ''<removed>'' , ''<unknown>'' , ''<itp>'' ]: + origlist.append( orig ) + embedlist.append( embedder ) + typelist.append( type ) + else: + if line.startswith( ''---BEGIN'' ): + found_begin = True + line = fembed.readline() +fembed.close() + +handle,fname_temp = tempfile.mkstemp() +ftemp = open( fname_temp , ''w'' ) + +lines = [] +cvelines = 0 +maxlines = 1000 +changed = False +fcve = open( fname_cve , ''r'' ) +line = fcve.readline() +while line: + + if not line.startswith( ''CVE'' ): + lines.append( line ) + else: + for n in range( 0 , len( lines ) ): + ftemp.write( lines[n] ) + if lines[n].startswith( ''\t- '' ): + package = lines[n].lstrip( ''\t- '' ).split( '' '' )[0] + + # inject TODOs for packages that embed affected versions + if package in origlist: + found_entry = False + index = origlist.index( package ) + for m in range( 0 , len( lines ) ): + if lines[m].startswith( ''\t- '' ): + other_package = lines[m].lstrip( ''\t- '' ).split( '' '' )[0] + if ( other_package == embedlist[index] ): + found_entry = True + elif ( lines[m] == todo_note % ( package , embedlist[index] , typelist[index] ) ): + found_entry = True + if not found_entry: + changed = True + ftemp.write( todo_note % ( package , embedlist[index] , typelist[index] ) + ''\n'' ) + + # inject TODOs for original sources that are embeded in affected packages +# while package in embedlist: +# index = embedlist.index( package ) +# found_entry = False +# for m in range( 0 , len( lines ) ): +# if lines[m].startswith( ''\t- '' ): +# other_package = lines[m].lstrip( ''\t- '' ).split( '' '' )[0] +# if ( other_package == origlist[index] ): +# found_entry = True +# elif ( lines[m] == todo_note2 % ( origlist[index] , package ) ): +# found_entry = True +# if not found_entry: +# changed = True +# ftemp.write( todo_note2 % ( origlist[index] , package ) + ''\n'' ) +# embedlist[index] = '''' + + ftemp.write( line ) + lines = [] + nlines = 0 + + cvelines += 1 + line = fcve.readline() +fcve.close() +ftemp.close() + +if changed: + mode = os.stat( fname_cve )[0] + os.system( ''cp %s %s'' % ( fname_temp , fname_cve ) ) + os.chmod( fname_cve , mode ) +os.system( ''rm %s'' % fname_temp ) Property changes on: bin/inject-embedded-code-copies ___________________________________________________________________ Added: svn:executable + * Modified: data/embedded-code-copies ==================================================================--- data/embedded-code-copies 2009-08-23 18:47:17 UTC (rev 12667) +++ data/embedded-code-copies 2009-08-24 00:59:44 UTC (rev 12668) @@ -256,7 +256,7 @@ chmlib - kchmviewer <unknown> (embed) -libavcodec/libavformat (source: ffmpeg) +ffmpeg (libavcodec/libavformat) - mplayer 1.0~rc2-14 (embed; bug #395252) - kino 1.0.0-1 - vlc <not-affected> (Links dynamically since initial release)
On Mon, 24 Aug 2009 00:59:44 +0000 Michael Gilbert Michael wrote:> introduction of inject-embedded-code-copieshello, i''ve noticed that embedded code copies can be troublesome to track, so i''ve developed a script that automatically adds TODOs for known code copies to the CVE list. i implemented both forward and reverse embeds, but i''ve commented out the reverse embeds section that seems to generate a lot of false positives. maybe this could be of use to someone doing a manual triage. anyway, running inject-embedded-code-copies generates about 400 changed lines, and i didn''t want to push such a big commit without warning. following is a sampling of the changes that would be commited. let me know if i should go ahead with that. also, i think it would be very useful to add this to set of scripts that are automatically run. mike --- data/CVE/list 2009-08-23 14:07:04.000000000 -0400 +++ data/CVE/list.new 2009-08-23 20:55:32.000000000 -0400 @@ -925,6 +925,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) + TODO: check embedded camlimages code copy [- advi <unfixed>] 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 ...) @@ -942,6 +943,7 @@ CVE-2009-XXXX [VLC: integer underflow in Real RTSP] - vlc 1.0.1-1 - mplayer <unfixed> + TODO: check embedded mplayer code copy [- xine-lib <unfixed>] NOTE: Posting on full-disclosure contains details CVE-2009-2655 (mshtml.dll in Microsoft Internet Explorer 7 and 8 on Windows XP SP3 ...) NOT-FOR-US: Microsoft Internet Explorer @@ -1415,11 +1417,13 @@ - neon27 0.28.6-1 (medium; bug #542926) - neon26 <unfixed> (medium; bug #542926) - neon <removed> (medium; bug #542926) + TODO: check embedded neon code copy [- gnome-vfs2 <unfixed>] CVE-2009-2473 [neon: billion laughs DoS attack] RESERVED - neon27 <not-affected> (neon27 is compiled to use libxml2 instead of expat) - neon26 <not-affected> (neon26 is compiled to use libxml2 instead of expat) - neon <removed> + TODO: check embedded neon code copy [- gnome-vfs2 <unfixed>] [etch] - neon <not-affected> (neon is compiled to use libxml2 instead of expat)
Hi, Michael S Gilbert wrote:> > hello, i''ve noticed that embedded code copies can be troublesome to > track, so i''ve developed a script that automatically adds TODOs for > known code copies to the CVE list.Nice, thanks. Some time ago I wrote bin/embedded-cleanup which performs some syntax checking and looks for not-existing packages. It would be great if anyone modifying embedded-code-copies run it and help reduce the number of issues it detects. It''s current output is: Non-existing package ''gpdf'', line:31 Non-existing package ''pdfkit.framework'', line:44 Non-existing package ''enblend-fuse'', line:130 Non-existing package ''gadu'', line:141 Non-existing package ''mozilla-firefox'', line:159 Non-existing package ''mozilla-thunderbird'', line:160 Non-existing package ''krb4'', line:178 Malformed line (195) detected: ''- atheme-services'' Malformed line (196) detected: ''- libbsd-arc4random-perl'' Malformed line (197) detected: ''- isakmpd'' Non-existing package ''usermin'', line:242 Non-existing package ''usermin'', line:243 Non-existing package ''mad'', line:277 Non-existing package ''python-beautifulsoup'', line:309 Non-existing package ''evince-gtk'', line:431 Non-existing package ''libpawlib2-lesstif'', line:435 Non-existing package ''claws-mail-html2-viewer'', line:439 Non-existing package ''libpawlib2-lesstif'', line:442 Non-existing package ''magic'', line:622 Non-existing package ''auth2db-frontend'', line:650 Non-existing package ''hobbix'', line:667 Non-existing package ''gforge-plugins-extra'', line:798 Non-existing package ''claws-mail-vcalendar-plugin'', line:804 Non-existing package ''icedove:'', line:880 Non-existing package ''firefox'', line:885 Non-existing package ''firefox-3.0'', line:887 Non-existing package ''firefox-3.1'', line:889 Non-existing package ''seamonkey'', line:891 Non-existing package ''thunderbird'', line:893 Non-existing package ''mozilla-thunderbird'', line:895 The firefox, seamonkey and thunderbird ones come from Ubuntu, which seems a bit odd to me that we are tracking them. All the script requires is a an alioth account so that it can query UDD to get the list of packages per release. Michael: by the way, the translate hash of my script may help a bit yours, but we should in general find a better approach. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net
Moritz Muehlenhoff
2009-Aug-26 17:29 UTC
[Secure-testing-team] inject-embedded-code-copies
On Sun, Aug 23, 2009 at 09:11:51PM -0400, Michael S Gilbert wrote:> On Mon, 24 Aug 2009 00:59:44 +0000 Michael Gilbert Michael wrote: > > introduction of inject-embedded-code-copies > > hello, i''ve noticed that embedded code copies can be troublesome to > track, so i''ve developed a script that automatically adds TODOs for > known code copies to the CVE list. > > i implemented both forward and reverse embeds, but i''ve commented out > the reverse embeds section that seems to generate a lot of false > positives. maybe this could be of use to someone doing a manual triage. > > anyway, running inject-embedded-code-copies generates about 400 changed > lines, and i didn''t want to push such a big commit without warning. > following is a sampling of the changes that would be commited. let me > know if i should go ahead with that. > > also, i think it would be very useful to add this to set of scripts > that are automatically run.You should redirect the TODOs in a file separate from CVE/list, otherwise it clutters the list too much. Cheers, Moritz
Michael S. Gilbert
2009-Aug-26 17:59 UTC
[Secure-testing-team] inject-embedded-code-copies
On Wed, 26 Aug 2009 19:29:10 +0200, Moritz Muehlenhoff wrote:> You should redirect the TODOs in a file separate from CVE/list,thanks for looking at this. i personally think that the cve list is the best destination. the reasoning is that cve TODOs are good indicators of what needs worked on and they are associated to specific cves. also, the TODOs show up on the security tracker website and are used by various scripts. yes, the first update from this script will commit over 400 changes, but assuming those issues are addressed or marked <not-affected>, subsequent updates will be much smaller. the important thing is that running this script increases awareness that a package that you''re dealing with is embedded elsewhere, and for that to be effective, it needs to update the cve list.> otherwise it clutters the list too much.if you believe that the current formatting is too cluttered, i am certainly open to suggestions. off the top of my head, for each affected cve, i could compact the current one line per embed into one line total for all embeds in that cve. mike
Moritz Muehlenhoff
2009-Aug-26 18:01 UTC
[Secure-testing-team] inject-embedded-code-copies
On Wed, Aug 26, 2009 at 01:59:58PM -0400, Michael S. Gilbert wrote:> On Wed, 26 Aug 2009 19:29:10 +0200, Moritz Muehlenhoff wrote: > > You should redirect the TODOs in a file separate from CVE/list, > > thanks for looking at this. i personally think that the cve list is > the best destination. the reasoning is that cve TODOs are good > indicators of what needs worked on and they are associated to specific > cves. also, the TODOs show up on the security tracker website and are > used by various scripts. > > yes, the first update from this script will commit over 400 changes, > but assuming those issues are addressed or marked <not-affected>, > subsequent updates will be much smaller. the important thing is that > running this script increases awareness that a package that you''re > dealing with is embedded elsewhere, and for that to be effective, it > needs to update the cve list. > > > otherwise it clutters the list too much. > > if you believe that the current formatting is too cluttered, i am > certainly open to suggestions. off the top of my head, for each > affected cve, i could compact the current one line per embed into one > line total for all embeds in that cve.Working through the list is mostly a QA issue. Just send it to a different file and add it to the PTS, this gives much more awareness for the maintainers. We already have enough TODOs of actual security issues which need attention. Cheers, Moritz
Moritz Muehlenhoff
2009-Aug-26 18:24 UTC
[Secure-testing-team] inject-embedded-code-copies
On Wed, Aug 26, 2009 at 02:25:19PM -0400, Michael S. Gilbert wrote:> On Wed, 26 Aug 2009 20:01:42 +0200, Moritz Muehlenhoff wrote: > > On Wed, Aug 26, 2009 at 01:59:58PM -0400, Michael S. Gilbert wrote: > > > On Wed, 26 Aug 2009 19:29:10 +0200, Moritz Muehlenhoff wrote: > > > > You should redirect the TODOs in a file separate from CVE/list, > > > > > > thanks for looking at this. i personally think that the cve list is > > > the best destination. the reasoning is that cve TODOs are good > > > indicators of what needs worked on and they are associated to specific > > > cves. also, the TODOs show up on the security tracker website and are > > > used by various scripts. > > > > > > yes, the first update from this script will commit over 400 changes, > > > but assuming those issues are addressed or marked <not-affected>, > > > subsequent updates will be much smaller. the important thing is that > > > running this script increases awareness that a package that you''re > > > dealing with is embedded elsewhere, and for that to be effective, it > > > needs to update the cve list. > > > > > > > otherwise it clutters the list too much. > > > > > > if you believe that the current formatting is too cluttered, i am > > > certainly open to suggestions. off the top of my head, for each > > > affected cve, i could compact the current one line per embed into one > > > line total for all embeds in that cve. > > > > Working through the list is mostly a QA issue. > > if you want, i can go through the generated list, triage most of the > TODOs, and mark them either not-affected, fixed, or unfixed before > uploading any changes; then only a few TODOs (for perhaps complicated > issues) will remain. it may require a significant amount of my time to > get this done, but i''ll do what it takes.Great, all confirmed issues can then be added as TODOs to CVE/list. Cheers, Moritz
Michael S. Gilbert
2009-Aug-26 18:25 UTC
[Secure-testing-team] inject-embedded-code-copies
On Wed, 26 Aug 2009 20:01:42 +0200, Moritz Muehlenhoff wrote:> On Wed, Aug 26, 2009 at 01:59:58PM -0400, Michael S. Gilbert wrote: > > On Wed, 26 Aug 2009 19:29:10 +0200, Moritz Muehlenhoff wrote: > > > You should redirect the TODOs in a file separate from CVE/list, > > > > thanks for looking at this. i personally think that the cve list is > > the best destination. the reasoning is that cve TODOs are good > > indicators of what needs worked on and they are associated to specific > > cves. also, the TODOs show up on the security tracker website and are > > used by various scripts. > > > > yes, the first update from this script will commit over 400 changes, > > but assuming those issues are addressed or marked <not-affected>, > > subsequent updates will be much smaller. the important thing is that > > running this script increases awareness that a package that you''re > > dealing with is embedded elsewhere, and for that to be effective, it > > needs to update the cve list. > > > > > otherwise it clutters the list too much. > > > > if you believe that the current formatting is too cluttered, i am > > certainly open to suggestions. off the top of my head, for each > > affected cve, i could compact the current one line per embed into one > > line total for all embeds in that cve. > > Working through the list is mostly a QA issue.if you want, i can go through the generated list, triage most of the TODOs, and mark them either not-affected, fixed, or unfixed before uploading any changes; then only a few TODOs (for perhaps complicated issues) will remain. it may require a significant amount of my time to get this done, but i''ll do what it takes.> Just send it to a different file and add it to the PTS, this gives > much more awareness for the maintainers. We already have enough TODOs > of actual security issues which need attention.an unaddressed embed is a security issue. mike
Michael S. Gilbert
2009-Aug-26 18:55 UTC
[Secure-testing-team] inject-embedded-code-copies
On Wed, 26 Aug 2009 20:24:36 +0200, Moritz Muehlenhoff wrote:> On Wed, Aug 26, 2009 at 02:25:19PM -0400, Michael S. Gilbert wrote: > > On Wed, 26 Aug 2009 20:01:42 +0200, Moritz Muehlenhoff wrote: > > > On Wed, Aug 26, 2009 at 01:59:58PM -0400, Michael S. Gilbert wrote: > > > > On Wed, 26 Aug 2009 19:29:10 +0200, Moritz Muehlenhoff wrote: > > > > > You should redirect the TODOs in a file separate from CVE/list, > > > > > > > > thanks for looking at this. i personally think that the cve list is > > > > the best destination. the reasoning is that cve TODOs are good > > > > indicators of what needs worked on and they are associated to specific > > > > cves. also, the TODOs show up on the security tracker website and are > > > > used by various scripts. > > > > > > > > yes, the first update from this script will commit over 400 changes, > > > > but assuming those issues are addressed or marked <not-affected>, > > > > subsequent updates will be much smaller. the important thing is that > > > > running this script increases awareness that a package that you''re > > > > dealing with is embedded elsewhere, and for that to be effective, it > > > > needs to update the cve list. > > > > > > > > > otherwise it clutters the list too much. > > > > > > > > if you believe that the current formatting is too cluttered, i am > > > > certainly open to suggestions. off the top of my head, for each > > > > affected cve, i could compact the current one line per embed into one > > > > line total for all embeds in that cve. > > > > > > Working through the list is mostly a QA issue. > > > > if you want, i can go through the generated list, triage most of the > > TODOs, and mark them either not-affected, fixed, or unfixed before > > uploading any changes; then only a few TODOs (for perhaps complicated > > issues) will remain. it may require a significant amount of my time to > > get this done, but i''ll do what it takes. > > Great, all confirmed issues can then be added as TODOs to CVE/list.btw, my script is already smart enough to exclude fixed embeds; it uses the <unfixed>/<removed>/<unknown>/<itp> tags in embedded-code-copies to determine if an issue is open or not. so as long as the data in embedded-code-copies is accurate, then my script already only generates TODOs for real issues. hence, when i am done with this triage, you can expect a lot of new <unfixed> entries (probably close to 200). mike
Moritz Muehlenhoff
2009-Aug-26 19:04 UTC
[Secure-testing-team] inject-embedded-code-copies
On Wed, Aug 26, 2009 at 02:55:03PM -0400, Michael S. Gilbert wrote:> On Wed, 26 Aug 2009 20:24:36 +0200, Moritz Muehlenhoff wrote: > > On Wed, Aug 26, 2009 at 02:25:19PM -0400, Michael S. Gilbert wrote: > > > On Wed, 26 Aug 2009 20:01:42 +0200, Moritz Muehlenhoff wrote: > > > > On Wed, Aug 26, 2009 at 01:59:58PM -0400, Michael S. Gilbert wrote: > > > > > On Wed, 26 Aug 2009 19:29:10 +0200, Moritz Muehlenhoff wrote: > > > > > > You should redirect the TODOs in a file separate from CVE/list, > > > > > > > > > > thanks for looking at this. i personally think that the cve list is > > > > > the best destination. the reasoning is that cve TODOs are good > > > > > indicators of what needs worked on and they are associated to specific > > > > > cves. also, the TODOs show up on the security tracker website and are > > > > > used by various scripts. > > > > > > > > > > yes, the first update from this script will commit over 400 changes, > > > > > but assuming those issues are addressed or marked <not-affected>, > > > > > subsequent updates will be much smaller. the important thing is that > > > > > running this script increases awareness that a package that you''re > > > > > dealing with is embedded elsewhere, and for that to be effective, it > > > > > needs to update the cve list. > > > > > > > > > > > otherwise it clutters the list too much. > > > > > > > > > > if you believe that the current formatting is too cluttered, i am > > > > > certainly open to suggestions. off the top of my head, for each > > > > > affected cve, i could compact the current one line per embed into one > > > > > line total for all embeds in that cve. > > > > > > > > Working through the list is mostly a QA issue. > > > > > > if you want, i can go through the generated list, triage most of the > > > TODOs, and mark them either not-affected, fixed, or unfixed before > > > uploading any changes; then only a few TODOs (for perhaps complicated > > > issues) will remain. it may require a significant amount of my time to > > > get this done, but i''ll do what it takes. > > > > Great, all confirmed issues can then be added as TODOs to CVE/list. > > btw, my script is already smart enough to exclude fixed embeds; it uses > the <unfixed>/<removed>/<unknown>/<itp> tags in embedded-code-copies to > determine if an issue is open or not.> so as long as the data in^^^^^^^^^^^^^^> embedded-code-copies is accurate, then my script already only generates^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^> TODOs for real issues. hence, when i am done with this triage, you can > expect a lot of new <unfixed> entries (probably close to 200).That''s exactly why the unfixed/TODO items should _not_ be commited until they''ve been verified manually. There''s too much noise in embedded code copies (like packages only embedding a small subset of code or outdated entries). Cheers, Moritz
Michael S. Gilbert wrote: [...]> > btw, my script is already smart enough to exclude fixed embeds; it uses > the <unfixed>/<removed>/<unknown>/<itp> tags in embedded-code-copies to > determine if an issue is open or not. so as long as the data in > embedded-code-copies is accurate, then my script already only generates > TODOs for real issues. hence, when i am done with this triage, you can > expect a lot of new <unfixed> entries (probably close to 200). >Does it also use the version information to determine what releases are affected? That''s an important consideration IMO. /me now goes back and finally tries to setup a copy of the tracker for the PTS integration Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net
Michael S. Gilbert
2009-Aug-26 19:18 UTC
[Secure-testing-team] inject-embedded-code-copies
On Wed, 26 Aug 2009 14:06:24 -0500, Raphael Geissert wrote:> Michael S. Gilbert wrote: > [...] > > > > btw, my script is already smart enough to exclude fixed embeds; it uses > > the <unfixed>/<removed>/<unknown>/<itp> tags in embedded-code-copies to > > determine if an issue is open or not. so as long as the data in > > embedded-code-copies is accurate, then my script already only generates > > TODOs for real issues. hence, when i am done with this triage, you can > > expect a lot of new <unfixed> entries (probably close to 200). > > > > Does it also use the version information to determine what releases are > affected? > That''s an important consideration IMO.no it does not use version information at this time, and i agree that that is definitely important. i will spend the time on that when i have a chance. mike
Michael S. Gilbert
2009-Aug-26 19:20 UTC
[Secure-testing-team] inject-embedded-code-copies
On Wed, 26 Aug 2009 21:04:08 +0200, Moritz Muehlenhoff wrote:> On Wed, Aug 26, 2009 at 02:55:03PM -0400, Michael S. Gilbert wrote: > > On Wed, 26 Aug 2009 20:24:36 +0200, Moritz Muehlenhoff wrote: > > > On Wed, Aug 26, 2009 at 02:25:19PM -0400, Michael S. Gilbert wrote: > > > > On Wed, 26 Aug 2009 20:01:42 +0200, Moritz Muehlenhoff wrote: > > > > > On Wed, Aug 26, 2009 at 01:59:58PM -0400, Michael S. Gilbert wrote: > > > > > > On Wed, 26 Aug 2009 19:29:10 +0200, Moritz Muehlenhoff wrote: > > > > > > > You should redirect the TODOs in a file separate from CVE/list, > > > > > > > > > > > > thanks for looking at this. i personally think that the cve list is > > > > > > the best destination. the reasoning is that cve TODOs are good > > > > > > indicators of what needs worked on and they are associated to specific > > > > > > cves. also, the TODOs show up on the security tracker website and are > > > > > > used by various scripts. > > > > > > > > > > > > yes, the first update from this script will commit over 400 changes, > > > > > > but assuming those issues are addressed or marked <not-affected>, > > > > > > subsequent updates will be much smaller. the important thing is that > > > > > > running this script increases awareness that a package that you''re > > > > > > dealing with is embedded elsewhere, and for that to be effective, it > > > > > > needs to update the cve list. > > > > > > > > > > > > > otherwise it clutters the list too much. > > > > > > > > > > > > if you believe that the current formatting is too cluttered, i am > > > > > > certainly open to suggestions. off the top of my head, for each > > > > > > affected cve, i could compact the current one line per embed into one > > > > > > line total for all embeds in that cve. > > > > > > > > > > Working through the list is mostly a QA issue. > > > > > > > > if you want, i can go through the generated list, triage most of the > > > > TODOs, and mark them either not-affected, fixed, or unfixed before > > > > uploading any changes; then only a few TODOs (for perhaps complicated > > > > issues) will remain. it may require a significant amount of my time to > > > > get this done, but i''ll do what it takes. > > > > > > Great, all confirmed issues can then be added as TODOs to CVE/list. > > > > btw, my script is already smart enough to exclude fixed embeds; it uses > > the <unfixed>/<removed>/<unknown>/<itp> tags in embedded-code-copies to > > determine if an issue is open or not. > > > so as long as the data in > ^^^^^^^^^^^^^^ > > embedded-code-copies is accurate, then my script already only generates > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > TODOs for real issues. hence, when i am done with this triage, you can > > expect a lot of new <unfixed> entries (probably close to 200). > > That''s exactly why the unfixed/TODO items should _not_ be commited until > they''ve been verified manually. There''s too much noise in embedded > code copies (like packages only embedding a small subset of code or > outdated entries).understood, and that''s why i am going to do this manual triage. we should probably force ourselves to be better at keeping embedded-code-copies up to date and accurate. mike
Michael S. Gilbert
2009-Aug-26 19:29 UTC
[Secure-testing-team] inject-embedded-code-copies
On Wed, 26 Aug 2009 14:06:24 -0500, Raphael Geissert wrote:> /me now goes back and finally tries to setup a copy of the tracker for the > PTS integrationonce you''ve got your local copy of the tracker up and running, can you post a howto to the list or insert documentation into the introduction? mike
[No need to send me a copy of the messages] Michael S. Gilbert wrote:> On Wed, 26 Aug 2009 14:06:24 -0500, Raphael Geissert wrote: >> /me now goes back and finally tries to setup a copy of the tracker for >> the PTS integration > > once you''ve got your local copy of the tracker up and running, can you > post a howto to the list or insert documentation into the introduction? >I just noticed I don''t actually need a full copy of the tracker so I won''t spend my time trying to figure out how, sorry. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net