Bug#645201: track uploads to proposed-updates
Hi, On Thu, 13 Oct 2011, Ansgar Burchardt wrote: > it would be nice if the security tracker could track uploads to p-u, > similar to how it already shows uploads to the security archive. And relate this with data/next-point-update.txt and next-oldstable-point-update.txt to mark the CVE as fixed in the p-u packages. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Sub-release information on per-source-package page
On Mon, 25 May 2015, Moritz Muehlenhoff wrote: If I understand the approach correctly, this mean we could as well add the fixed versions through (o)s-pu directly to the data/CVE/list once accepted by the stable release managers instead of keeping them in separate list data/next-(oldstable-)point-update.txt and merge it at point release time? I don't think anything would change wrt spu/ospu? People don't have spu in their apt sources, so a fix is really only visible to them once it has moved into stable proper. Correct but that is not a problem since the security tracker doesn't watch spu/opu... so we can put version numbers of packages which are there and let the tracker decide that the corresponding CVE are still open since the fixed versions are not yet in stable/oldstable. IMO the usage of this intermediary file is a nuisance that hides useful information in the tracker... 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/20150527081409.gc18...@home.ouaza.com
Re: Is CVE-2014-0254 really affecting Qt and not only Windows?
Hi Petter, On Thu, 30 Apr 2015, Petter Reinholdtsen wrote: But neither Redhat nor Ubuntu believe this CVE affect their software. Also NVD only list windows as affected. Are you sure Qt is affected by this CVE, or could there be a typo somewhere? It was indeed a typo. The qt4-x11 update I just pushed fixed CVE-2013-0254 but I incorrectly marked CVE-2014-0254 instead. Fixed the data in the tracker. Thanks for the notification! PS: Next time please use debian-...@lists.debian.org for squeeze related issues (or at least put it in copy, you will have a quicker answer there). -- 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/20150430085649.ga26...@home.ouaza.com
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-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 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-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 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
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, 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-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
Re: debsecan now on Gitorious
On Wed, 25 Feb 2015, Florian Weimer wrote: * Raphael Hertzog: On Sun, 22 Feb 2015, Florian Weimer wrote: I've moved the debsecan Git repository to Gitorious. Please speak up if you want to be added to the push ACL. Out of curiosity, why not on git.debian.org ? As far as I understand it, there's no effective separation between user accounts on git.debian.org once you start doiing Git pushes. If you want that you need a dedicated project where you control membership. But in general we often have git repositories writable to all DD and rely on git commit notifications to ensure nothing unwanted happens. BTW it looks like Gitorious is going away. 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/20150311074135.ga30...@home.ouaza.com
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
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
Bug#761859: prototype ready
On Tue, 24 Feb 2015, Holger Levsen wrote: On Dienstag, 24. Februar 2015, Richard Hartmann wrote: Depending on your layout, you don't really need two different JSON files, though. how would you distinguish between squeeze, which includes lts and security, and squeeze, which doesnt? Same for wheezy (and security and not). You could decide to different keys for the aggregated data and for the non-aggregated data. It's actually a good idea. It could look like this: pkg: CVE: ... repositories: squeeze: squeeze-lts: ... jessie: jessie-security: ... releases: squeeze: ... jessie: Release is a general concept that includes multiple respositories. And in repositories you have finer-graind data by real repositories. 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/20150225093624.ga18...@home.ouaza.com
Re: debsecan now on Gitorious
Hi, On Sun, 22 Feb 2015, Florian Weimer wrote: I've moved the debsecan Git repository to Gitorious. Please speak up if you want to be added to the push ACL. Out of curiosity, why not on git.debian.org ? 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/20150225094108.gb18...@home.ouaza.com
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. pkg: cve: 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, 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
Bug#761859: prototype ready
On Sun, 22 Feb 2015, Holger Levsen wrote: new output is attached in compressed form. The only missing data I see is the Debian bug report assigned to each CVE. And you call the file json but it contains YAML :-) Otherwise, I see that you have the raw data per real suite (aka squeeze is never fixed, only squeeze-lts is fixed) and I would prefer having data consolidated by release (i.e. you get the squeeze status by merging squeeze, squeeze-security and squeeze-lts, wheezy by merging wheezy and wheezy-security, etc.). Is that possible ? 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/20150223133826.gb2...@home.ouaza.com
Re: Bug#761730: tracker.d.o: please provide links to https://security-tracker.debian.org/tracker/source-package/$PKG
On Wed, 18 Feb 2015, Raphael Hertzog wrote:
One thing that comes to my mind is that we probably also want the
associated Debian bug number when there's an associated bug report.
So instead of a plain CVE identifier we probably want a hash:
{ 'id': 'CVE--', 'bug': '12345', 'severity': 'low' }
That way we could also export the severity and easily add more data
in case of future needs.
And I just thought that I would like to have the status... in particular
to differentiate no-dsa issues.
status: open|no-dsa|end-of-life|resolved ?
or just
status: open|resolved
no-dsa: True|False
This would suggest to have a single list of issues per suite and have
the status/severity in the data of each CVE:
'bind9': {
'squeeze': {
'CVE--': {
'status': 'open|resolved',
'severity': 'unimportant|low|normal|high|unknown',
'no-dsa': True|False,
'end-of-life': True|False,
},
...
],
'wheezy': [
...
]
},
--
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/20150218104500.ga10...@home.ouaza.com
Re: Bug#761730: tracker.d.o: please provide links to https://security-tracker.debian.org/tracker/source-package/$PKG
Hi,
On Tue, 16 Sep 2014, Raphael Hertzog wrote:
Let's not continue that bad tradition. If anything it should provide
either YAML or JSON with something structured:
bind9:
squeeze:
open:
- CVE-XXX
- CVE-YYY
open-unimportant:
- ...
resolved:
- ...
wheezy:
...
One thing that comes to my mind is that we probably also want the
associated Debian bug number when there's an associated bug report.
So instead of a plain CVE identifier we probably want a hash:
{ 'id': 'CVE--', 'bug': '12345', 'severity': 'low' }
That way we could also export the severity and easily add more data
in case of future 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/20150218101411.ga9...@home.ouaza.com
Bug#762781: security-tracker: Provide list of candidates for dsa-needed.txt/dla-needed.txt
Hi, On Thu, 25 Sep 2014, Holger Levsen wrote: On Donnerstag, 25. September 2014, Raphaël Hertzog wrote: It would be nice if the security tracker could provide by release a list of packages with open vulnerabilities (i.e. neither unimportant nor tagged as no-dsa) that are not yet listed in dsa-needed.txt/dla-needed.txt depending on the case. thanks for this description, sounds implementable ;-) The annoying part is that the mapping of release = file to use changes over time. There's a one year period where oldstable is the realm of the security team and only afterwards it gets into dla-needed.txt. I wish we could use a unified process. After all dsa-needed.txt already accepts package/stable and package/oldstable for the period where the security team takes care of both. Maybe we could just always use that scheme... Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → 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/20140926153809.gb15...@x230-buxy.home.ouaza.com
Guidance on no-dsa and adding entries to dsa/dla-needed.txt
Hello, I'm in the process of reviewing open CVE in oldstable and deciding whether it must be added to dla-needed.txt or not. I have multiple questions: 1/ is there a page on the security tracker that lists packages with open vulnerabilities in stable/oldstable which are neither unimportant, nor marked no-dsa and not present in dsa/dla-needed ? (I could not find one) Shall I file a wishlist request for this ? 2/ Since we decided early-on to mark squeeze as no-dsa when wheezy was also marked as such, I wonder what I should do when no such decision has been made yet (i.e. the package is not in dsa-needed.txt but the CVE entry also doesn't have any no-dsa or unimportant tag). I would like to have some guidelines on when it's appropriate to mark something as no-dsa or when it's better to add it to dsa/dla-needed (apparently I made a bad decision once already, since Moritz reverted http://anonscm.debian.org/viewvc/secure-testing?view=revisionrevision=28950) This information is not available in http://security-team.debian.org/security_tracker.html Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → 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/20140922123017.gb20...@x230-buxy.home.ouaza.com
Re: Bug#761730: tracker.d.o: please provide links to https://security-tracker.debian.org/tracker/source-package/$PKG
Hi, On Tue, 16 Sep 2014, Holger Levsen wrote: the information gathered in the security-tracker should be displayed in the package tracker.d.o. It's already there, see the 20 security issues in https://tracker.debian.org/pkg/linux When you click on the question mark you get access to the link. This should be improved so that the link is directly accessible without going through the extended info but the info should be there. Have you seen a package where there was no such entry and where it should have had one? Each source package has a URL of the form https://security-tracker.debian.org/tracker/source-package/bind9 bind9 is not in the list exported by the tracker at https://security-tracker.debian.org/tracker/data/pts/1 So the list seems to be limited to open issues in sid. We might want to improve this and provide a better overview of the release where security issues are open. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → 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/20140916072541.gb25...@x230-buxy.home.ouaza.com
Re: Bug#761730: tracker.d.o: please provide links to https://security-tracker.debian.org/tracker/source-package/$PKG
On Tue, 16 Sep 2014, Holger Levsen wrote: On Dienstag, 16. September 2014, Raphael Hertzog wrote: Let's not continue that bad tradition. If anything it should provide either YAML or JSON with something structured: I agree. Any preference? JSON is more web-friendly, I would pick that. YAML is the best choice for files manually managed by humans but when it's generated by code, JSON is a better idea IMO. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → 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/20140916120311.gg23...@x230-buxy.home.ouaza.com
