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
signature.asc
Description: This is a digitally signed message part.
