Hi, On Montag, 9. März 2015, Raphael Hertzog wrote: > But I wonder why you have such problems? Aren't you storing the result > in memory and then letting a json lib output the data? I dont, as I've converted the previous yaml output to json, because I liked the humand readability of the result... > > Open questions: > > - should the output include description fields if the value is "null"? > > - should the output include nodsa fields if the value is "null"? > > - should the output include remote fields if the value is "null"? > No to the 3 above questions. ok, changed where applicable. > That said your "repositories" field is weird for now... first it's an array > and not a dictionnary for a reason that I don't understand. And the values > contain only a dictionnary with a single key mapping "codename => > version". it's the current version as opposed in that repo... > > And then I thought, urgency would be a per issue field (and thus would be > > the same for different suites), with the exception that the (suite > > specific) "end- of-life" information is also stored there. > > Turned out I was wrong, there are many more cases where the urgency of > > issues *is* suite-specific (plus, issues can affect several packages.) > I looked at some of the cases you listed, but the original CVE file only > has a single urgency... it might be that this urgency is not in line with > the urgency retrieved from NVD but that's OK. Our urgency should override > that one for our needs. when there are suite specific urgencies, the json lists those... cheers, Holger
Attachment:
signature.asc
Description: This is a digitally signed message part.