Bug#761859: security-tracker json deployed
Hi, On Freitag, 27. Februar 2015, Paul Wise wrote: To clarify, I was suggesting keep the version numbers in the repositories section but only keep fixed version numbers in the releases section. Also, the fixed version numbers appear to be incorrect, for example the website says CVE-2012-6656 was fixed in eglibc 2.13-38+deb7u7 but the json says it was fixed in 2.13-38+deb7u8. https://security-tracker.debian.org/tracker/CVE-2012-6656 this is a fine example, 2.13-38+deb7u7 is indeed not returned by my queries. looking into this now. (and then into json format errors...) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#761859: security-tracker json deployed
On Mon, 09 Mar 2015, Holger Levsen wrote: I dont, as I've converted the previous yaml output to json, because I liked the humand readability of the result... Even for the YAML output I would have used a YAML library, so it doesn't make more sense for me :-) 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... I don't understand. IIRC we said the content of repositories and releases was supposed to have the same structure. The only difference was that it applied to different versions of packages. 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... Well, I'm saying that I was agreeing with you. The severity ought to be a issue/package property, not a issue/package/repository one. And I don't understand the discrepancy you get because for me there are only two sources of urgencies: - those set on lines like - tcllib 1.16-dfsg-2 (low; bug #780100) - those coming from the NVD database And in the problematic cases that you listed I only saw one priority set with a line of the first type (and never found multiple priorities with lines like [squeeze] - package something (low; ...). 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/ -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150309153923.ga19...@home.ouaza.com
Re: Bug#761859: security-tracker json deployed
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.
Bug#761859: security-tracker json deployed
Hi,
On Montag, 9. März 2015, Raphael Hertzog wrote:
I don't understand. IIRC we said the content of repositories and
releases was supposed to have the same structure. The only difference
was that it applied to different versions of packages.
I think the confusion might be because you stated something else than Paul..
Currently there are two dictionaries in the output, one called releases
containing dictionaries containing information about the status of a given
issue in a release, and another with repositories and the current version.
eg
almanah: [
{
debianbug: 702905,
description: Almanah Diary 0.9.0 and 0.10.0 does not encrypt the
database when closed, which allows local users to obtain sensitive information
by reading the database.,
issue: CVE-2013-1853,
releases: {
jessie: {
status: resolved,
urgency: low**,
version: 0.9.1-1
},
sid: {
status: resolved,
urgency: low**,
version: 0.9.1-1
},
squeeze: {
status: resolved,
urgency: unimportant,
version: 0
},
wheezy: {
status: resolved,
urgency: low**,
version: 0.9.1-1
}
},
repositories: {
jessie: 0.11.1-1,
sid: 0.11.1-1,
squeeze: 0.7.3-1,
wheezy: 0.9.1-1
},
scope: local
}
],
repositories has the current versions, releases has the fixed versions if
there are any. Oh well, why did I pick this example, sigh. so squeeze is not
affected...
I think I will release what I have now and we can look for further needed
tuning then.
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...
Well, I'm saying that I was agreeing with you. The severity ought to be a
issue/package property, not a issue/package/repository one. And I don't
understand the discrepancy you get because for me there are only two
sources of urgencies:
- those set on lines like - tcllib 1.16-dfsg-2 (low; bug #780100)
- those coming from the NVD database
the problem is that the urgency field is abused to also hold the information
about end-of-life, not yet assigned and unimportant, thats basically why
urgency has to be suite specific...
(and this is why I think the db needs a redesign: it has been abused to store
things which were not planned, and it shows.)
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
Bug#761859: security-tracker json deployed
Hi, I have deployed this now. It might be that fixed_version=0 means not affected but i'm not sure yet and my mind wants a break (for a moment)... cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#761859: security-tracker json deployed
Hi Florian, On Donnerstag, 26. Februar 2015, Florian Weimer wrote: There used to be a job that downloaded the full description from the NVD web service and put it into the nvd_data table (update-nvd and DB.updateNVD()). The web service looks at this table and prefers the descriptions found there. I've just confirmed, the job is still there and run regularily by cron. I've also updated my local security-tracker to include the long description and will push this to soler shortly... cheers, Holger signature.asc Description: This is a digitally signed message part.
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/
--
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150309105902.ga9...@home.ouaza.com
External check
CVE-2015-1783: 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. -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yvd2o-0004yx...@soler.debian.org
