External check
CVE-2016-10624: TODO: check CVE-2017-16005: TODO: check CVE-2017-16011: TODO: check CVE-2017-16012: TODO: check CVE-2017-16014: TODO: check CVE-2017-16021: TODO: check CVE-2017-16023: TODO: check CVE-2017-16026: TODO: check CVE-2017-16030: TODO: check CVE-2017-16118: TODO: check CVE-2017-16119: TODO: check CVE-2017-16129: TODO: check CVE-2017-16652: TODO: check CVE-2018-10855: RESERVED CVE-2018-1103: TODO: check CVE-2018-11039: RESERVED CVE-2018-11040: RESERVED CVE-2018-11385: TODO: check CVE-2018-11386: TODO: check CVE-2018-11406: TODO: check CVE-2018-11407: TODO: check CVE-2018-11408: TODO: check CVE-2018-12029: RESERVED CVE-2018-12264: TODO: check CVE-2018-12265: TODO: check CVE-2018-5804: RESERVED CVE-2018-5805: RESERVED CVE-2018-5806: RESERVED -- The output might be a bit terse, but the above ids are known elsewhere, check the references in the tracker. The second part indicates the status of that id in the tracker at the moment the script was run.
Re: Dealing with renamed source packages during CVE triaging
On Fri, Jun 15, 2018 at 04:34:14PM +1000, Brian May wrote: > Moritz Muehlenhoff writes: > > > On Wed, Jun 13, 2018 at 05:19:40PM +1000, Brian May wrote: > >> "as I said in the mailing list discussion, I don't like the usage of the > >> undetermined tag... we use it to hide stuff we can't investigate under > >> the carpet, I would much prefer that we put it as directly > >> when it's the case, or otherwise." > > > > Of course, those can be resolved; it just needs someone to do the analysis > > work. > > Switching to some other tags (and incorrect ones!) doesn't change anything. > > Seems like this a mute point anyway, as from the comments you left in > the pull request, you don't like this approach of automatically adding > entries in data/CVE/list. Fair enough. > > So we could write a script, lets say: > bin/list-potential-packages-affected-by-code-copies You're mixing two things; my comment above refers to , those are one-off investigations and don't need any particular tooling. > That generates a report of all packages that we need to check. I assume > we would need some way of marking packages that we have checked and > found to be not affected, so we can get a list of packages that need > immediate attention and don't repeatedly check the same package multiple > times. How should we do this? Maybe another file in the security tracker > repository? Maybe start with the script initially and see whether it's useful as an approach in general. State tracking can be discussed/added later. Lots of the false positives will result from crappy/outdated entries in embedded-code-copies, so fixing those up will drastically reduce false positives. Cheers, Moritz
Re: Dealing with renamed source packages during CVE triaging
On Fri, Jun 15, 2018 at 05:21:55PM +1000, Brian May wrote: > Brian May writes: > > > So we could write a script, lets say: > > bin/list-potential-packages-affected-by-code-copies > > In investigating the possibility of this, I noticed the scripts in > lib/python/sectracker use legacy python coding standards. > > I have updated these files on my local box to work with Python 3, but > refraining from pushing for now, because of the possibilty I might break > something important. When the Debian Security Tracker was created, Python 3 didn't even exist yet :-) Feel free to make a pull request, I don't think we have a specific dependency on Python 2 modules anywhere. But it might take a bit to get reviewed/deployed as it's not a high priority issue. Cheers, Moritz
Re: Dealing with renamed source packages during CVE triaging
Brian May writes: > So we could write a script, lets say: > bin/list-potential-packages-affected-by-code-copies In investigating the possibility of this, I noticed the scripts in lib/python/sectracker use legacy python coding standards. I have updated these files on my local box to work with Python 3, but refraining from pushing for now, because of the possibilty I might break something important. Is Python 2 compatability still required? -- Brian May
