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-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150420101931.ga24...@home.ouaza.com
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 ... 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-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150414074657.ga20...@home.ouaza.com
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 ... 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-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150323145335.gb29...@home.ouaza.com
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 ... 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 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 ... 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, 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-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150317121512.GA4746@pisco.westfalen.local
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 ... 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, 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-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150317120944.GB2948@pisco.westfalen.local
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 ... 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, 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 ... 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-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150316230303.gd7...@home.ouaza.com
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
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-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150316161909.ga4...@home.ouaza.com
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-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150316110503.ga32...@home.ouaza.com
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,
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
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] - (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 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 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 $/; }, {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 $/; }); 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-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cad77+grk3jxytz2jpxbznhso9-0ugrvutqnmh0p9me-swxo...@mail.gmail.com
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 "", line 1, in
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
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 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-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150227083558.ga24...@lorien.valinor.li
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
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-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4nkl5tu@mid.deneb.enyo.de
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
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
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...
On Wed, 25 Feb 2015, Holger Levsen wrote: > so it would display: > > version: $some_version_in_lts > release: squeeze > > which is kinda wrong/inaccurate... If you want to be picky, you can add the repository in the data for the aggregated part. : : repositories: squeeze: version: $squeeze_version ... squeeze-lts: version: $some_version_in_lts ... releases: squeeze: version: $some_version_in_lts repository: squeeze-lts ... Some other comments on the YAML output I saw: "Debian" for the bug number is probably best renamed to "bug" and there's no point in including the leading "#". Otherwise it looks ok. Thanks for your work on this! -- 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/20150225095207.gc18...@home.ouaza.com
Bug#761859: security tracker json...
Hi Raphael, thanks for your feedback! I got a consistent idea now. On Mittwoch, 25. Februar 2015, Raphael Hertzog wrote: > > - if a CVE is neither fixed in lts/security/(squeeze|wheezy), but the > > version in lts/security differs from squeeze|wheezy, which version+suite > > to display as affected? > The aggregate view should use the latest version available from all the > repositories associated to the release of interest. so it would display: version: $some_version_in_lts release: squeeze which is kinda wrong/inaccurate... But ok, I'll implemented both outputs (full+aggregated) and then we can see if this is a bug or a feature :) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#761859: security tracker json...
Hi, On Tue, 24 Feb 2015, Holger Levsen wrote: > on the latter I have some questions: > > - if a CVE is fixed in lts/security but not squeeze|wheezy, the aggregated > json will display it as fixed in lts or security. IMO you should always aggregate the data into the associated base release. aka: squeeze/wheezy/jessie/sid Always using the codename for consistency. > - if a CVE is neither fixed in lts/security/(squeeze|wheezy), the aggregated > output should display it as open in ??? Same as above. > - if a CVE is neither fixed in lts/security/(squeeze|wheezy), but the version > in lts/security differs from squeeze|wheezy, which version+suite to display > as > affected? The aggregate view should use the latest version available from all the repositories associated to the release of interest. 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/20150225092924.ga18...@home.ouaza.com
