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
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
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
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
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
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
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
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
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
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
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
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
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...
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
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.
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
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
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...
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
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
* 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
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
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?
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.
pkg:
cve:
repositories:
squeeze:
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:
25 matches
Mail list logo
