External check
CVE-2016-10537: TODO: check CVE-2016-10541: TODO: check CVE-2016-10621: TODO: check CVE-2016-10624: TODO: check CVE-2016-10656: TODO: check CVE-2017-16005: TODO: check CVE-2017-16021: TODO: check CVE-2017-16023: TODO: check CVE-2017-16026: TODO: check CVE-2017-16030: TODO: check CVE-2017-16113: TODO: check CVE-2017-16114: TODO: check CVE-2017-16116: TODO: check CVE-2017-16118: TODO: check CVE-2017-16119: TODO: check CVE-2017-16129: TODO: check CVE-2017-16136: TODO: check CVE-2017-16137: TODO: check CVE-2017-16138: TODO: check CVE-2018-1000193: TODO: check CVE-2018-1000194: TODO: check CVE-2018-1000195: TODO: check CVE-2018-11813: TODO: check CVE-2018-6514: RESERVED CVE-2018-6515: 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
I've finalized a prototype during my research on this problem, which I have detailed on GitLab, as it's really code that should be merged. It would also benefit from wider attention considering it affects more than LTS now. Anyways, the MR is here: https://salsa.debian.org/security-tracker-team/security-tracker/merge_requests/4 Comments are welcome there or here. For what it's worth, I reused Lamby's crude parser because I wanted to get the prototype out the door. I am also uncertain that a full parser can create the CVE/list file as is reliably without introducing inconsistent diffs... I also drifted into the core datastructures of the security tracker, and wondered if it would be better to split up our large CVE/list file now that we're using git. I had mixed results. For those interested, it is documented here: https://salsa.debian.org/security-tracker-team/security-tracker/issues/2 Cheers! a. -- If it's important for you, you'll find a way. If it's not, you'll find an excuse. - Unknown
Re: Dealing with renamed source packages during CVE triaging
On 2018-06-08 03:29:38, Brian May wrote:
> Antoine Beaupré writes:
>
>> Right now, it seems that all scripts that hammer at those files do so
>> with their own ad-hoc parsing code. Is that the recommended way of
>> chopping those files up? Or is there a better parsing library out there?
>
> It sounds like we really good do with a good parsing library. Maybe one
> that supports making changes too.
>
> I could make a start on this.
As I mentioned in the other thread, I am uncertain where to go from
here. Some scripts use JSON, others parse the files by hand... I also
found out yesterday after writing this that there is *already* a parsing
library in the security tracker. It can parse {CVE,DSA,DLA}/list files
and lives in lib/python/bugs.py, but it's somewhat coupled with the
sqlite database - i'm not sure it's usable standalone.
But yeah, maybe clarifying all this stuff would help, for sure... I
would recommend not writing yet another library from scratch however, as
we probably have a dozen such parser already and it's confusing enough
as it is. ;)
a.
--
L'ennui avec la grande famille humaine, c'est que tout le monde veut
en être le père.
- Mafalda
Re: Dealing with renamed source packages during CVE triaging
Antoine Beaupré writes: > Right now, it seems that all scripts that hammer at those files do so > with their own ad-hoc parsing code. Is that the recommended way of > chopping those files up? Or is there a better parsing library out there? It sounds like we really good do with a good parsing library. Maybe one that supports making changes too. I could make a start on this. Obligatory XKCD: https://xkcd.com/927/ -- Brian May
