Bug#761859: security-tracker json deployed
Hi Raphael, On Montag, 20. April 2015, Raphael Hertzog wrote: I just noticed that DLA/DSA end up referenced as security issues. See for example DLA-204-1 and DLA-27-1 assigned to file. That's a bug, thanks for notifying. I will fix it soon, latest on saturday when I'll add oldoldstable support to the security-tracker. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#761859: security-tracker json deployed
Hi,
On Tue, 14 Apr 2015, Holger Levsen wrote:
On Dienstag, 14. April 2015, Raphael Hertzog wrote:
Can you quickly export the undetermined status in the JSON so that I can
filter them out?
ok, done.
state will now be one of resolved, undetermined and open.
I just noticed that DLA/DSA end up referenced as security issues. See
for example DLA-204-1 and DLA-27-1 assigned to file.
Is that on purpose? To me at least it seems wrong to have those in
the exported JSON at the same level than security issues...
file: {
...
DLA-204-1: {
releases: {
squeeze: {
repositories: {
squeeze: 5.04-5+squeeze5,
squeeze-lts: 5.04-5+squeeze9,
squeeze-security: 5.04-5+squeeze5
},
status: open,
urgency: not yet assigned
}
}
},
DLA-27-1: {
releases: {
squeeze: {
fixed_version: 5.04-5+squeeze6,
repositories: {
squeeze: 5.04-5+squeeze5,
squeeze-lts: 5.04-5+squeeze9,
squeeze-security: 5.04-5+squeeze5
},
status: resolved,
urgency: not yet assigned
}
}
},
},
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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
Hi Raphael, On Dienstag, 14. April 2015, Raphael Hertzog wrote: Can you quickly export the undetermined status in the JSON so that I can filter them out? ok, done. state will now be one of resolved, undetermined and open. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#761859: security-tracker json deployed
Hi, On Mon, 23 Mar 2015, Raphael Hertzog wrote: On Mon, 23 Mar 2015, Holger Levsen wrote: I also noticed that we have nowhere data that says that an issue is undetermined... maybe those issues should be entirely dropped? I agree that those issues should not be displayed in the tracker, but I'm not entirely convinced they should be dropped from the json... (that's also how I understood Moritz in this bug) - but if you insist, it's easy to drop them. I'm fine having the data in the JSON as long as I can filter them out in some way. Can you quickly export the undetermined status in the JSON so that I can filter them out? Thank you! 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
Hi, On Dienstag, 17. März 2015, Raphael Hertzog wrote: The repository dictionary has what you are looking for. The releases dictionary indeed lists all versions in all existing releases. The repository dictionary doesn't have the data that I'm interested in. ack Maybe you would prefer the releases dict to only have keys squeeze, wheezy, jessie and sid and an additional sub-release key? Yes, the entries in releases must be predictable. I must be able to lookup issue_data['releases']['squeeze']['status'] and have the status in squeeze no matter what sub-release has the latest version. ok. so i will add a subrelease key, speciying the first subrelease where the issue is fixed. subrelease will have one of these values: null, 'security' or lts'. I also noticed that we have nowhere data that says that an issue is undetermined... maybe those issues should be entirely dropped? I agree that those issues should not be displayed in the tracker, but I'm not entirely convinced they should be dropped from the json... (that's also how I understood Moritz in this bug) - but if you insist, it's easy to drop them. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#761859: security-tracker json deployed
On Mon, 23 Mar 2015, Holger Levsen wrote: I also noticed that we have nowhere data that says that an issue is undetermined... maybe those issues should be entirely dropped? I agree that those issues should not be displayed in the tracker, but I'm not entirely convinced they should be dropped from the json... (that's also how I understood Moritz in this bug) - but if you insist, it's easy to drop them. I'm fine having the data in the JSON as long as I can filter them out in some way. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
On Tue, Mar 17, 2015 at 08:17:03AM +0800, Paul Wise wrote: On Tue, 2015-03-17 at 00:03 +0100, Raphael Hertzog wrote: I also noticed that we have nowhere data that says that an issue is undetermined... maybe those issues should be entirely dropped? I don't understand why we have that status in the first place. But my first try at identifying issues open in squeeze (i.e. an improved https://security-tracker.debian.org/tracker/status/release/oldstable) led me to showing many such issues... and I want to filter them out. I don't think we should hide issues, if the secteam hasn't had time to sort through them, exposing them to maintainers and other folks can only help recruit more people to help maintain the data. We don't hide anything, undetermined is only used for cases, where an issue was assessed, but no actionable information is available, e.g. for secretive advisories from security companies selling 0-days, unclear bugs or secretive vendors like Oracle. So, sorting them out makes sense. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
On Tue, Mar 17, 2015 at 01:09:44PM +0100, Moritz Mühlenhoff wrote: On Tue, Mar 17, 2015 at 08:17:03AM +0800, Paul Wise wrote: On Tue, 2015-03-17 at 00:03 +0100, Raphael Hertzog wrote: I also noticed that we have nowhere data that says that an issue is undetermined... maybe those issues should be entirely dropped? I don't understand why we have that status in the first place. But my first try at identifying issues open in squeeze (i.e. an improved https://security-tracker.debian.org/tracker/status/release/oldstable) led me to showing many such issues... and I want to filter them out. I don't think we should hide issues, if the secteam hasn't had time to sort through them, exposing them to maintainers and other folks can only help recruit more people to help maintain the data. We don't hide anything, undetermined is only used for cases, where an issue was assessed, but no actionable information is available, e.g. for secretive advisories from security companies selling 0-days, unclear bugs or secretive vendors like Oracle. So, sorting them out makes sense. I meant filtering here. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
Hi, On Mon, 16 Mar 2015, Holger Levsen wrote: Hi Raphael, On Montag, 16. März 2015, Raphael Hertzog wrote: I'm currently trying to use the generated json but the data below the releases field doesn't correspond to what we discussed. It contains entries like wheezy-security or squeeze-security when it was supposed to have only the underlying release names squeeze or wheezy. The repository dictionary has what you are looking for. The releases dictionary indeed lists all versions in all existing releases. The repository dictionary doesn't have the data that I'm interested in. Maybe you would prefer the releases dict to only have keys squeeze, wheezy, jessie and sid and an additional sub-release key? Yes, the entries in releases must be predictable. I must be able to lookup issue_data['releases']['squeeze']['status'] and have the status in squeeze no matter what sub-release has the latest version. I also noticed that we have nowhere data that says that an issue is undetermined... maybe those issues should be entirely dropped? I don't understand why we have that status in the first place. But my first try at identifying issues open in squeeze (i.e. an improved https://security-tracker.debian.org/tracker/status/release/oldstable) led me to showing many such issues... and I want to filter them out. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
On Tue, 2015-03-17 at 00:03 +0100, Raphael Hertzog wrote: I also noticed that we have nowhere data that says that an issue is undetermined... maybe those issues should be entirely dropped? I don't understand why we have that status in the first place. But my first try at identifying issues open in squeeze (i.e. an improved https://security-tracker.debian.org/tracker/status/release/oldstable) led me to showing many such issues... and I want to filter them out. I don't think we should hide issues, if the secteam hasn't had time to sort through them, exposing them to maintainers and other folks can only help recruit more people to help maintain the data. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#761859: security-tracker json deployed
Hi, On Mon, 09 Mar 2015, Holger Levsen wrote: 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)... Another nice thing to add in the generated file is whether the package is listed in dsa-needed.txt and dla-needed.txt. That would be two boolean fields at the source package level (default value of False if missing). 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
On Mon, 16 Mar 2015, Raphael Hertzog wrote:
On Mon, 09 Mar 2015, Holger Levsen wrote:
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)...
Another nice thing to add in the generated file is whether the package is
listed in dsa-needed.txt and dla-needed.txt.
That would be two boolean fields at the source package level (default value
of False if missing).
I'm currently trying to use the generated json but the data below the
releases field doesn't correspond to what we discussed. It contains
entries like wheezy-security or squeeze-security when it was supposed
to have only the underlying release names squeeze or wheezy.
Example with CVE-2014-9663 in freetype if you need one:
{
debianbug: 777656,
description: The tt_cmap4_validate function in sfnt/ttcmap.c in FreeType
before 2.5.4 validates a certain length field before that field's value is
completely calculated, which allows remote attackers to cause a denial of
service (out-of-bounds read) or possibly have unspecified other impact via a
crafted cmap SFNT table.,
issue: CVE-2014-9663,
releases: {
jessie: {
status: resolved,
urgency: high**,
version: 2.5.2-3
},
sid: {
status: resolved,
urgency: high**,
version: 2.5.2-3
},
squeeze-security: {
status: open,
urgency: high**,
version: 2.4.2-2.1+squeeze4
},
wheezy-security: {
status: resolved,
urgency: high**,
version: 2.4.9-1.1+deb7u1
}
},
repositories: {
jessie: 2.5.2-3,
sid: 2.5.2-4,
squeeze: 2.4.2-2.1+squeeze4,
squeeze-security: 2.4.2-2.1+squeeze4,
wheezy: 2.4.9-1.1,
wheezy-security: 2.4.9-1.1+deb7u1
},
scope: remote
},
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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
Hi Raphael,
On Montag, 16. März 2015, Raphael Hertzog wrote:
I'm currently trying to use the generated json but the data below the
releases field doesn't correspond to what we discussed. It contains
entries like wheezy-security or squeeze-security when it was supposed
to have only the underlying release names squeeze or wheezy.
The repository dictionary has what you are looking for. The releases
dictionary indeed lists all versions in all existing releases.
Maybe you would prefer the releases dict to only have keys squeeze, wheezy,
jessie and sid and an additional sub-release key?
Example with CVE-2014-9663 in freetype if you need one:
thanks, examples are always good to discuss these things!
{
debianbug: 777656,
releases: {
jessie: {
status: resolved,
},
sid: {
status: resolved,
},
squeeze-security: {
status: open,
},
wheezy-security: {
status: resolved,
}
},
repositories: {
jessie: 2.5.2-3,
sid: 2.5.2-4,
squeeze: 2.4.2-2.1+squeeze4,
squeeze-security: 2.4.2-2.1+squeeze4,
wheezy: 2.4.9-1.1,
wheezy-security: 2.4.9-1.1+deb7u1
},
},
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
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 Thu, Feb 26, 2015 at 5:08 PM, Holger Levsen hol...@layer-acht.org wrote:
I haven't tested the output against a json validator yet... so feedback
welcome and I do expect some more work to do...
I am seeing the same issues as Rapahel.
A poor man's checker if you are parseable in theory would be:
wget https://security-tracker.debian.org/tracker/data/json
perl -e 'use Data::Dumper; use JSON; open(JSON, json);
$data=from_json(do {local $/; JSON}, {relaxed = 1}); print Dumper
$data'
and to make sure it's actually valid:
perl -e 'use Data::Dumper; use JSON; open(JSON, json);
$data=from_json(do {local $/; JSON}); print Dumper $data'
FWIW, I agree that serializing should be done by a JSON library; that
way you don't have to care about the details.
Richard
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
Hi Paul, On Fri, Feb 27, 2015 at 07:31:10AM +0800, Paul Wise wrote: On Thu, 2015-02-26 at 17:41 +0100, Holger Levsen wrote: On Donnerstag, 26. Februar 2015, Paul Wise wrote: I noticed the description fields are truncated, is that intentional? that's all that is stored in the db... Are you sure? By way of example, take a look at CVE-2012-0833, the description listed on the web page is much longer than in the JSON. https://security-tracker.debian.org/tracker/CVE-2012-0833 See https://bugs.debian.org/761859#185 . In the data/CVE/list file itself, it also just only contains the truncated one (which is fine in this case). Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
Hi Paul,
On Donnerstag, 26. Februar 2015, Paul Wise wrote:
I noticed the description fields are truncated, is that intentional?
that's all that is stored in the db...
What about making the structure like this?
why? :)
I'm guessing the code only
produces one instance of each package.
yes
{
package1: {...},
package2: {...},
}
I haven't tested the output against a json validator yet... so feedback
welcome and I do expect some more work to do...
Not a helpful error but the Python json loader tracebacks, try:
import json
with open('json') as f: data = json.load(f)
thanks, will give it a try later. (Currently waiting for more feedback before
touching the code again...)
- 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?
Probably not.
ack
- 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)
Hmm, I wouldn't have thought there would be a version present for
unfixed issues? The raw data in the CVE list certainly doesn't have
version numbers for unfixed issues.
the tracker shows them all the time, eg on
https://security-tracker.debian.org/tracker/CVE-2013-2131
I'm thinking omit such versions.
/me too
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
Bug#761859: security-tracker json deployed
control: tags -1 + pending Hi, 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... Important change: - CVEs are now called issues as there are a few different issues than CVEs included. 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? - 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) 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.) Unedited debug output (so you can look at these issues if you really care), please add spaces mentally: this should never happen unimportantlowCVE-2015-1563 this should never happen mediumhigh**CVE-2008-5234 this should never happen lowhigh**CVE-2008-5237 this should never happen mediummedium**CVE-2008-5239 this should never happen lowmedium**CVE-2008-5240 this should never happen lowmedium**CVE-2008-5241 this should never happen mediummedium**CVE-2008-5242 this should never happen medium**lowCVE-2011-2516 this should never happen high**lowCVE-2013-1436 this should never happen medium**lowCVE-2011-4613 this should never happen not yet assignedlowTEMP-000-269968 this should never happen low**lowCVE-2011-4028 this should never happen unimportanthighCVE-2012-0064 this should never happen unimportanthigh**CVE-2012-2118 this should never happen medium**lowCVE-2013-6424 this should never happen unimportantnot yet assignedCVE-2014-8103 cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#761859: security-tracker json deployed
On Thu, 26 Feb 2015 17:08:57 +0100 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.
Cool!
I noticed the description fields are truncated, is that intentional?
Personally I would suggest to keep those at full length.
What about making the structure like this? I'm guessing the code only
produces one instance of each package.
{
package1: {...},
package2: {...},
}
I haven't tested the output against a json validator yet... so feedback
welcome and I do expect some more work to do...
Not a helpful error but the Python json loader tracebacks, try:
import json
with open('json') as f: data = json.load(f)
- 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?
Probably not.
- 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)
Hmm, I wouldn't have thought there would be a version present for
unfixed issues? The raw data in the CVE list certainly doesn't have
version numbers for unfixed issues. I'm thinking omit such versions.
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#761859: security-tracker json deployed
* Holger Levsen: On Donnerstag, 26. Februar 2015, Paul Wise wrote: I noticed the description fields are truncated, is that intentional? that's all that is stored in the db... 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761859: security-tracker json deployed
On Thu, 2015-02-26 at 17:41 +0100, Holger Levsen wrote: On Donnerstag, 26. Februar 2015, Paul Wise wrote: I noticed the description fields are truncated, is that intentional? that's all that is stored in the db... Are you sure? By way of example, take a look at CVE-2012-0833, the description listed on the web page is much longer than in the JSON. https://security-tracker.debian.org/tracker/CVE-2012-0833 What about making the structure like this? why? :) More logical, uses less bytes for the string package. the tracker shows them all the time, eg on https://security-tracker.debian.org/tracker/CVE-2013-2131 Ah, the first table is the version numbers of the package in each distribution, fixed or not. The second table is fixed version numbers. I'm thinking omit such versions. /me too 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 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
