[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#761859: security-tracker json deployed



Hi,

On Thu, 26 Feb 2015, Holger Levsen wrote:
> so I've deployed my patches now and you can get json at 
> https://security-tracker.debian.org/tracker/data/json now.
> 
> I haven't tested the output against a json validator yet... so feedback 
> welcome and I do expect some more work to do...

Yeah, a JSON parser is not accepting the file:
$ python
>>> import json
>>> a = json.load(open('data.json'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/json/__init__.py", line 290, in load
    **kw)
  File "/usr/lib/python2.7/json/__init__.py", line 338, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

There are multiple problems:
- first it doesn't allow "commas" (,) at the end of lists or dictionnaries
- then you start the "releases" dictionnary with a "[" instead of a "{"
  (and same for the end)

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?

> 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.

> - for the releases with issue status != "resolved", should the version be 
> ommitted? (as its rather meaningless then... also the repositories fields also 
> contain those versions. (and those should be kept IMO)

Ack.

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".

> 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.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


Reply to: