Bug#1001451: Candidate script updates
On Tue, 2022-01-11 at 11:20 +, Neil Williams wrote: > I might need to brush up on my Perl and make a patch for lintian which > downloads the sec tracker JSON and checks the CVE list in the .changes > file - warnings from lintian are more likely to get fixed prior to > upload. Depends if you think this happens sufficiently often that it is > a problem worth solving. (Considering how long it's been since I did > that amount of code in Perl, maybe I'm better filing the bug against > lintian and seeing if someone else can come up with a patch... - again, > only if it happens sufficiently often.) FTR, lintian does not do any network requests, so this approach won't be accepted. The best option you can get is a script to do the download at the lintian release time. Unfortunately this means the data will get outdated quickly and make the check less useful. This check could be added to devscripts, debsecan or duck. The sectracker JSON is very large, so I think that a new API will be needed for any tool that implements such a check. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1001191: security-tracker: include more information in page titles
Package: security-tracker Severity: wishlist It would be nice to include some more information in page titles, so that records of those page titles in search engine results, browser tabs and browser history are more useful to visitors to the site. Here are examples of the potential changes that could be made: URL: https://security-tracker.debian.org/tracker/source-package/samba Current: Information on source package samba Potential: Security info for Debian samba source package: 26 open issues, 3 open unimportant issues, 132 resolved issues, 62 security announcements URL: https://security-tracker.debian.org/tracker/CVE-2021-20254 Current: CVE-2021-20254 Potential: CVE-2021-20254 - samba - #987811 - unfixed in buster - A flaw was found in samba. The samba smbd file server [...] URL: https://security-tracker.debian.org/tracker/DSA-5015-1 Current: DSA-5015-1 Potential: DSA-5015-1 - samba - security update - CVE-2020-25717 fixed in buster (security) version 2:4.9.5+dfsg-5+deb10u2 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#949260: security-tracker: add cvedetails.com to Source?
On Sun, Jan 19, 2020 at 3:05 AM Dmitry Smirnov wrote: > It might be nice to add "cvedetails.com" to CVE Source links. > https://www.cvedetails.com/cve/CVE-2019-13072/ This doesn't appear to add any details that aren't on Mitre: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13072 -- bye, pabs https://wiki.debian.org/PaulWise
Re: Open Source
On Mon, Nov 4, 2019 at 7:57 AM Lindsey Lassen wrote: > Hello, I am unsure if I am contacting the correct department for my concern. > I have had your open source software added on my cell phone and I have never > authorized your company nor anyone else for that matter. It would be a great > resolve and weight off my shoulders, if you could direct me in the right > direction to get some answers in regards to locating who is responsible for > this occurring, as well as, how I might be able to remove and eliminate this > from happening in the future. Could you describe the software in question or provide a screenshot of the software? It is unlikely that anyone from Debian had any contact with your cell phone. It is unlikely that any software from Debian is able to be installed on any cell phones. -- bye, pabs https://wiki.debian.org/PaulWise
Re: request for changing SUSE reference URL
On Tue, Sep 17, 2019 at 11:48 PM Alexandros Toptsoglou wrote: > Could you please change this and from now on point to SUSE bugs using > bugzilla.suse.com which is the correct and basically the one that we > always reference? I've made a commit changing all bugzilla.novell.com references to bugzilla.suse.com. https://salsa.debian.org/security-tracker-team/security-tracker/commit/b37757a5658d6f141d207fea480539abf366924e The links on every CVE page supplied by the first hunk will require the Debian security team to update the live deployment of the security tracker, the Notes sections of individual CVE pages will get updated automatically. To avoid more references to bugzilla.novell.com appearing, I think it would help if you could get all bugzilla.novell.com URLs to redirect to their equivalent bugzilla.suse.com URL. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian HTTP repo got manipulated , Debian HTTPs repo doesnt work
On Tue, Oct 23, 2018 at 12:33 AM bo0od wrote: > yay! , yeah it worked thx alot :) In addition, we have some Tor-based Onion services available: https://onion.debian.org/ PS: this mailing list is about the security-tracker.debian.org site, not about Debian mirrors or their security so please ask any further questions about them on debian-user. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#908678: security-tracker - Breaks salsa.d.o
On Thu, Sep 13, 2018 at 7:37 PM, Salvatore Bonaccorso wrote: > Do you have any hints at us on what we could look at to faciliate/help > more salsa maintainers? I think I read on IRC that the main thing is that the design of git is not optimised for having large and growing files that change on every commit. So splitting them up into to one file per CVE/DSA/DLA/etc might help? Or switching from git to a database or something like restic or borg. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#907723: link package versions on security-tracker to source packages
On Sat, Sep 1, 2018 at 5:53 PM, Holger Levsen wrote: > On Sat, Sep 01, 2018 at 12:43:58PM +0800, Paul Wise wrote: >> > So, I always go to [1] with my web browser, copy the URL of the .dsc file >> > and then dget that .dsc file. >> This misses out verifying apt signatures. > > the .dsc file is signed and dget verifies it. dget does not verify the apt signatures though, since it does not download them. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#907723: link package versions on security-tracker to source packages
On Sat, Sep 1, 2018 at 5:48 AM, Mike Gabriel wrote: > when working for the LTS team, I regularly need to download source packages > from the LTS version of Debian. My development machine normally runs a newer > Debian version, having deb-src URLs for Debian LTS in sources.list is > possible but not a good option (for me) as it increases latency for apt > update. I would suggest you use either apt-venv or chdist (from devscripts) to enable you to have the apt metadata for LTS and stable releases so that you can easily download the source using apt. I do this and have a cron job to automatically run apt update for each chdist. > So, I always go to [1] with my web browser, copy the URL of the .dsc file > and then dget that .dsc file. This misses out verifying apt signatures. -- bye, pabs https://wiki.debian.org/PaulWise
Re: RFS: zodbpickle/0.6.0-1 [ITP]
On Mon, 2018-04-23 at 22:17 +0200, Julien Muchembled wrote: > I suggest to update embedded-code-copies because this package forks > the 'pickle' modules of Python 2.7.6 and 3.3.2 > python2.7 > - zodbpickle (embed) > NOTE: embeds stdlib modules: pickle, cpickle > > I am surprised to see no entry for any version of Python 3. > Maybe start one with python3.6 Added both. > However, given the warning at the top of > https://docs.python.org/3/library/pickle.html > I am not sure it's useful to bother about the security of this code. > > And unfortunately, the many changes in Python are not merged into zodbpickle. I'd suggest that you work with ZODB upstream to remove zodbpickle from their dependencies/codebase. It is technical debt, problematic for security and there are likely faster ways to serialise data in Python. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: pulling in other vulnerability databases
On Thu, 2018-01-25 at 11:05 -0500, Antoine Beaupré wrote: > I'm not sure what to say to nodesecurity.io folks I've already contacted them multiple times in 2014 and once in 2016, about incorporating CVEs into their workflow. The responses were positive but didn't result in much change, except when the issues were sent to oss-sec or Mitre by the Debian security team or myself or others. Most of their recent advisories have CVEs but some don't. I'm guessing the researchers who discovered the issues are getting CVEs. I think the best outcome would be if NodeSecurity could become a CNA so they could issue CVEs immediately with each advisory they send out. https://marc.info/?i=1399944995.3095.25.camel@chianamo https://marc.info/?i=1411952951.6106.20.ca...@bonedaddy.net https://marc.info/?l=oss-security=139757263925026=2 http://www.openwall.com/lists/oss-security/2016/02/20/2 http://www.openwall.com/lists/oss-security/2016/01/12/2 > pabs, did you have any issues in mind that were problematic here > specifically? Here is one example culled from my email archive: http://bugs.debian.org/862712 https://nodesecurity.io/advisories/338 https://security-tracker.debian.org/tracker/862712 It didn't end up getting added to the security tracker, didn't get a CVE and only got fixed in Debian after I filed a bug about it. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
[PATCH] Accept more variants of standard CVE identifier format
Transform the given identifier to a standard one and
redirect to the standard form if it is in the database:
* convert spaces to dashes
* convert lowercase to uppercase
---
bin/tracker_service.py | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/bin/tracker_service.py b/bin/tracker_service.py
index 9cbbccc8be..5a890f561d 100755
--- a/bin/tracker_service.py
+++ b/bin/tracker_service.py
@@ -329,9 +329,9 @@ data source.""")],
return RedirectResult(self.url_debian_bug(url, str(bugnumber)),
permanent=False)
-if 'A' <= obj[0] <= 'Z':
-# Bug names start with a capital letter.
-return self.page_bug(url, obj, redirect)
+page = self.page_bug(url, obj, redirect)
+if page is not None:
+return page
if self.db.isSourcePackage(c, obj):
return RedirectResult(self.url_source_package(url, obj, full=True))
@@ -339,20 +339,23 @@ data source.""")],
return self.page_not_found(url, obj)
def page_bug(self, url, name, redirect):
+# Transform the name to a standard one
+name_s = name.replace(' ', '-').upper()
+
# FIXME: Normalize CAN-* to CVE-* when redirecting. Too many
# people still use CAN.
-if redirect and name[0:4] == 'CAN-':
-name = 'CVE-' + name[4:]
+if redirect and name_s[0:4] == 'CAN-':
+name_s = 'CVE-' + name_s[4:]
cursor = self.db.cursor()
try:
-bug = bugs.BugFromDB(cursor, name)
+bug = bugs.BugFromDB(cursor, name_s)
except ValueError:
if redirect:
-if name[0:4] == 'CVE-':
-return RedirectResult(self.url_cve(url, name),
+if name_s[0:4] == 'CVE-':
+return RedirectResult(self.url_cve(url, name_s),
permanent=False)
-return self.page_not_found(url, name)
+return None
if bug.name <> name or redirect:
# Show the normalized bug name in the browser address bar.
return RedirectResult(url.scriptRelativeFull(bug.name))
--
2.15.1
Re: Security Tracker Frame Options Header
On Fri, Jan 12, 2018 at 4:59 PM, Mattia Dorigatti wrote: > I have a question. Why do the security tracker sites have the > X-Frame-Options:sameorigin header set? Because I've wanted to keep an eye on > some CVEs I've created a simple html site with three iframes and the refresh > meta tag so that I could put it on an extra monitor and have a look at the > status. But I can't do that if that header is set. Why is this and can it be > changed? All debian.org hosts use this header where possible. As you can see in the Mozilla documentation, it is used to prevent clickjacking attacks as well as hosts passing off content as their own, so I'm not sure it is a good idea to disable it. I think it might be best for you to use a browser extension to achieve the autorefresh and open a window for each CVE. You could also just subscribe to the Debian bug mail for each bug associated with the CVEs you are interested in. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options https://www.debian.org/Bugs/Developer#subscribe -- bye, pabs https://wiki.debian.org/PaulWise
Re: heads-up: stretch release and changes to security-tracker
On Mon, Jun 12, 2017 at 3:37 AM, Salvatore Bonaccorso wrote: > I'm attaching the *preliminary* set of changes which I plan to > activate once stretch is released. Wow, there really is a horribly large amount of hard-coding of things that should be fetched from the archive instead. I've added a reference to your mail here: https://wiki.debian.org/SuitesAndReposExtension#secure-testing -- bye, pabs https://wiki.debian.org/PaulWise
Re: heads-up: stretch release and changes to security-tracker
On Sat, May 27, 2017 at 5:06 PM, Chris Lamb wrote: > Can you briefly explain what changes you are refering to? If appropriate, please document the hard-coding here too: https://wiki.debian.org/SuitesAndReposExtension -- bye, pabs https://wiki.debian.org/PaulWise
Re: how to apply the fix for CVE-2016-5195
On Mon, Oct 24, 2016 at 9:02 PM, Omar Abu Ajamieh wrote: > i have multiple Debian servers with this kernel version ( 3.2.0-4-amd64 #1 > SMP Debian 3.2.63-2 ) and i’m trying to fix the CVE-2016-5195 on it ,so > could please help me in how i can determine if my server is vulnerable or > not and how i can apply the fix on it ? Upgrade your packages and then reboot. More info here: https://lists.debian.org/debian-lts-announce/2016/10/msg00026.html -- bye, pabs https://wiki.debian.org/PaulWise
Re: Reserved CVEs
On Fri, Sep 2, 2016 at 5:59 PM, Ivan Vasylivskyi wrote: > Why some vulnerabilities listed by Ubuntu Security Tracker which are public > and populated marked as RESERVED on mitre.org ? This mailing list is for the Debian Security Tracker, not the Ubuntu security tracker. A lot of the time the vulnerabilities are publicly released elsewhere before Mitre makes them public on their site. > Can I compile the list of vulnerabilities is update them on mitre.org ? Not sure what you mean by that. -- bye, pabs https://wiki.debian.org/PaulWise
Re: please add icdiff to embedded-code-copies
On Mon, May 16, 2016 at 5:17 AM, Sascha Steinbiss wrote: > as the maintainer, I’d like to let you know the package ‘icdiff’ (new in > unstable) contains a modified fork of Python’s difflib code. According to > upstream, it’s "based on Python's difflib.HtmlDiff, with changes to provide > console output instead of HTML output". Thanks, committed. > icdiff > - libpython-stdlib (modified-embed) > NOTE: core functionality based on Python difflib code with changed > output format FYI, the format is the other way around and deals with source packages. Also, I think icdiff is more of a fork than modified-embed? -- bye, pabs https://wiki.debian.org/PaulWise
Re: tracking security issues without CVEs
On Mon, Mar 28, 2016 at 10:34 PM, Andrew Deck wrote: > On a related note, does anyone know what happened to OSF and the OSVDB? > There still seem to be blog updates, but I remember OSVDB having a web > UI, and the OSF website seems to be down. They have officially closed the OSVDB site: https://blog.osvdb.org/2016/04/05/osvdb-fin/ -- bye, pabs https://wiki.debian.org/PaulWise
Bug#818253: security-tracker: do not mention TEMP-*-* identifiers on source package pages
Package: security-tracker Severity: wishlist Tags: newcomer The TEMP-*-* identifiers are not meant to be referenced. On source package pages we should: Reference the Debian bug number in the link and the link text for issues that have a Debian bug number. Just put "TEMP" in the text for issues without a bug number instead of referencing the full TEMP-*-* identifier. https://security-tracker.debian.org/tracker/source-package/simplesamlphp -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#818250: security-tracker: use bug report based URLs in preference to TEMP-*-* based URLs
Package: security-tracker Severity: wishlist Tags: newcomer The TEMP-*-* identifiers are not meant to be referenced. So I think we should to use bug report URLs in preference to TEMP-*-* based URLs: Redirect from TEMP-*-* based URLs to bug based ones. Stop redirecting from bug based URLs to TEMP-*-* based ones. Here is an example of equivalent bug and TEMP-*-* based URLs: https://security-tracker.debian.org/tracker/817162 https://security-tracker.debian.org/tracker/TEMP-0817162-612833 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: tracking security issues without CVEs
On Sun, Mar 6, 2016 at 12:33 PM, Brian May wrote: > Just wondering if there is some other way we can track security issues > for when CVEs are not available. ... > For example, if there are no CVEs are we able to use OVEs instead? > > http://www.openwall.com/ove This sounds like a good idea to me. Do you know of any issues where OVEs were used? Is there any project who uses them regularly? I wonder if we should be discussing this more widely, for example on oss-sec? > Thinking of imagemagick here, it has a lot of security issues, and > requests for CVEs are not getting any responses. It sounds like Mitre has quite a backlog: https://marc.info/?i=1456968329.26654.16.ca...@bonedaddy.net https://marc.info/?i=CANO=ty1yvjf505lzrj7utg5ypbys1gabo4bd0e5h95pup62...@mail.gmail.com https://cve.mitre.org/data/board/archives/2015-11/msg00018.html -- bye, pabs https://wiki.debian.org/PaulWise
Bug#780892: security-tracker: please show unsupported packages as unsupported instead of unimportant
Package: security-tracker Severity: important Please change the Urgency field for issues on unsupported packages from unimportant to unsupported. Having unimportant in the urgency field is very misleading. Currently the only indication that a package is unsupported is in the notes section of each issue. The page for each source package should say Open unsupported issues instead of Open unimportant issues. Here are some examples of what I am talking about: https://security-tracker.debian.org/tracker/CVE-2014-6393 https://security-tracker.debian.org/tracker/source-package/node-express -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
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
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: prototype ready
On Mon, 2015-02-23 at 14:59 +0100, Holger Levsen wrote: surely. I just wasn't sure whether this should be done on the security-tracker side or by it's users... or I could provide two versions: json-full and json(- aggregated) - do you think that would be useful? I think it would be useful to provide the non-aggregated version for folks who only use some of the stable suites. Not sure if the sectracker has information about stable-proposed-updates but if so it would be good to include it too. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#761859: prototype ready
On Sun, 22 Feb 2015 00:37:49 +0100 Holger Levsen wrote: I have a prototype ready, see attached... I noticed that fixed issues are not listed, we need that so people can look up the security history of any package by clicking a 'security' link in the links section. Just an item link: True|False would be enough, True for anything that has any info in the security tracker. I see a bunch of urgency set to high** and medium**, should it be high and medium instead? I think it might be a good idea to include attack range information (local/remote/etc). -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#761859: prototype ready
On Sun, 2015-02-22 at 19:00 +0100, Holger Levsen wrote:
On Sonntag, 22. Februar 2015, Paul Wise wrote:
I see a bunch of urgency set to high** and medium**, should it
be high and medium instead?
this comes directly from the database, so I don't think it should be modified.
Hmm, it appears that these are the default urgency from NVD and the ones
without asterisks are ones set by SVN committers. That doesn't appear to
be a distinction worth preserving but it is fine to do so.
Please ensure that this json is linked to from the front page of the
security tracker and from the security tracker documentation so that
people building on it can find it easily. It is vastly more friendly to
potential consumers than the current output consumed by the PTS and the
current output consumed by debsecan. We've already had people looking
for JSON and trying to use the debsecan data.
I think for other consumers of the data (not distro-tracker), exposing
fixed version numbers might be interesting. For instance, someone with
500 machines who aggregates host/package/version information and then
correlates that with the list of security issues from the sectracker.
I should stop bike-shedding though :)
Anyway, the current JSON is good for the distro-tracker from a content
perspective (so please deploy) but it doesn't load using the python JSON
module so it is probably not valid JSON, I'd suggest using Python's
json.dump instead of whatever method you are using now.
with open('json') as f: data = json.load(f)
...
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 369, in decode
raise ValueError(errmsg(Extra data, s, end, len(s)))
ValueError: Extra data: line 1 column 4 - line 428027 column 1 (char 3 -
10590028)
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#761353: security-tracker: remove hardcoding of various data from Debian's apt repositories
Package: security-tracker Severity: wishlist Control: block -1 by 761348 Various places in the security tracker hardcode various data from Debian's apt repositories, including those from the list below. It would be nice if the security-tracker could fetch that data (daily) from the Debian apt repositories instead. The list of repositories could be fetched from the Repositories file proposed in #761348. The list of repositories to fetch data from. The list of suite names (unstable etc). The list of architectures available in each suite. The list of components available in each suite. The codename for each active suite. The list codenames of archived suites. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#744830: security-tracker: link to doc/narrative_introduction on s-t.d.o/tracker/data/report needs updating
Package: security-tracker Severity: normal The Reporting problems page[1] on the security tracker website points at [2] but this page simply says that the page has moved elsewhere without giving a full link to the location of the new page. Please either update the link or add a full link to the new page to the narrative introduction page. https://security-tracker.debian.org/tracker/data/report http://svn.debian.org/viewvc/secure-testing/doc/narrative_introduction?view=co The content of this file was moved to public/security_tracker This file will be removed in the future. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#741713: security-tracker: in the list of resolved issues, list releases and versions where fixes happened
Package: security-tracker Severity: wishlist It would be useful to people using modified versions of packages if the security tracker listed releases and versions where fixes happened in the list of resolved issues. Combined with a fix for #611162 and or a link to a debdiff or the fixed version from snapshot.d.o this could be very useful for people wanting to apply fixes to internally modified packages and to the security teams of Debian derivatives. https://security-tracker.debian.org/tracker/source-package/samba -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#727742: security-tracker: allow searching for CVE 2013-4327 (with a space)
Package: security-tracker Severity: wishlist In some places on the web and mailing lists, CVEs are referenced with a space instead of a dash (CVE 2013-4327 instead of CVE-2013-4327). It would be nice if I could copy and paste these into the search box and have the right CVE show up without having to adjust the space to a dash. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#660190: security-tracker: add per-maintainer page (with half-baked patch)
On Mon, 2012-03-12 at 22:56 -0400, Michael Gilbert wrote: There is a removed_packages table that you can use to check whether the package is currently in debian or not. The foreign key stuff is not about whether or not the package is in Debian, just about deleting maintainer information when packages are removed from the database. It's still the same source package. You could step through each suite separately on the maintainer pages since yes they will each have different sets of issues. You could limit results by checking that the release is in a supported release (squeeze,wheezy,sid). All packages are considered in the archive until they're not in any release. But I really think you want a listing of issues per suite per maintainer. Feel free to update the patch to do that, I don't have any more time to spend on this. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#660190: security-tracker: add per-maintainer page (with half-baked patch)
On Mon, 2012-03-12 at 21:16 -0400, Michael Gilbert wrote: Also, why is c.execute(PRAGMA foreign_keys=ON) necessary? sqlite doesn't enforce foreign key constraints by default: https://sqlite.org/foreignkeys.html#fk_enable I'm using those to ensure maintainers are deleted when source packages are deleted from the database. At a cursory glance, this seems more complicated that it needs to be. You're creating an id for each source package, but that is redundant since the package name itself is a unique id. All you should need is a table with only sourcepkg names and maintainer fields. Then when you process a view on (for example) a maintainer page you can step through all sourcepkg names listed as associated with that maintainer via that table. The source package name is definitely not unique since there are multiple suites that could have a line in the source package table. I'm not sure if the foreign key stuff would work with non-numeric keys. If a package gets removed from sid, we still want the issues present in stable to be listed on the maintainer's page. Going with your suggestion would mean that we would not know which maintainers to remove when a package is deleted from one particular suite. There is also a debugging print statement. Removed in my local checkout. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#660190: security-tracker: add per-maintainer page (with half-baked patch)
On Fri, 2012-02-17 at 17:36 +0800, Paul Wise wrote: The attached patch implements a first pass at a per-maintainer page of security issues. It involves some database schema changes to it will require a full reimport of all the data. Does anyone have some time to review my patch? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#660190: security-tracker: add per-maintainer page (with half-baked patch)
Package: security-tracker Severity: wishlist The attached patch implements a first pass at a per-maintainer page of security issues. It involves some database schema changes to it will require a full reimport of all the data. My SQL knowledge isn't great, so there are some deficiencies: I'm not sure if the adding another table is the right way to go, nor if I used the right table name. I'm not sure if the getBugsForMaintainer is correct, especially wrt version numbers/releases/etc. I am not sure how to implement a getDSAsForMaintainer function to add DSAs related to the maintainer at the bottom of the page. -- bye, pabs http://wiki.debian.org/PaulWise Index: lib/python/security_db.py === --- lib/python/security_db.py (revision 18462) +++ lib/python/security_db.py (working copy) @@ -38,6 +38,7 @@ import sys import types import zlib +import email.utils import debian_support import dist_config @@ -123,6 +124,9 @@ # Enable WAL. This means that updates will not block readers. c.execute(PRAGMA journal_mode = WAL) +# Enable foreign keys +c.execute(PRAGMA foreign_keys=ON) + self.schema_version = 22 self._initFunctions() @@ -198,15 +202,23 @@ cursor.execute( CREATE TABLE source_packages -(name TEXT NOT NULL, +(id INTEGER, +name TEXT NOT NULL, release TEXT NOT NULL, subrelease TEXT NOT NULL, archive TEXT NOT NULL, version TEXT NOT NULL, version_id INTEGER NOT NULL DEFAULT 0, -PRIMARY KEY (name, release, subrelease, archive))) +UNIQUE (name, release, subrelease, archive), +PRIMARY KEY(id ASC))) cursor.execute( +CREATE TABLE source_package_maintainers +(source_package_id INTEGER NOT NULL, +maintainer TEXT NOT NULL, +FOREIGN KEY(source_package_id) REFERENCES source_packages(id) ON DELETE CASCADE)) + +cursor.execute( CREATE TABLE binary_packages (name TEXT NOT NULL, release TEXT NOT NULL, @@ -348,14 +360,14 @@ AND sidp.release = 'sid' AND sidp.subrelease = '' AND sidp.archive = sp.archive AND sidst.bug_name = st.bug_name -AND sidst.package = sidp.rowid) AS unstable_vulnerable, +AND sidst.package = sidp.id) AS unstable_vulnerable, COALESCE((SELECT NOT vulnerable FROM source_packages AS tsecp, source_package_status AS tsecst WHERE tsecp.name = sp.name AND tsecp.release = 'wheezy' AND tsecp.subrelease = 'security' AND tsecp.archive = sp.archive AND tsecst.bug_name = st.bug_name -AND tsecst.package = tsecp.rowid), 0) AS testing_security_fixed, +AND tsecst.package = tsecp.id), 0) AS testing_security_fixed, (SELECT range_remote FROM nvd_data WHERE cve_name = st.bug_name) AS remote, (EXISTS (SELECT * FROM package_notes_nodsa AS pnd @@ -363,7 +375,7 @@ AND pnd.package = sp.name AND pnd.release = 'wheezy')) AS no_dsa FROM source_package_status AS st, source_packages AS sp -WHERE st.vulnerable 0 AND sp.rowid = st.package +WHERE st.vulnerable 0 AND sp.id = st.package AND sp.release = 'wheezy' AND sp.subrelease = '' ORDER BY sp.name, st.urgency, st.bug_name) @@ -380,7 +392,7 @@ AND pnd.package = sp.name AND pnd.release = '%s')) AS no_dsa FROM source_package_status AS st, source_packages AS sp -WHERE st.vulnerable 0 AND sp.rowid = st.package +WHERE st.vulnerable 0 AND sp.id = st.package AND sp.release = '%s' AND sp.subrelease = '' AND NOT COALESCE((SELECT NOT vulnerable FROM source_packages AS secp, source_package_status AS secst @@ -388,7 +400,7 @@ AND secp.release = '%s' AND secp.subrelease = 'security' AND secp.archive = sp.archive AND secst.bug_name = st.bug_name -AND secst.package = secp.rowid), 0) +AND secst.package = secp.id), 0) ORDER BY sp.name, urgency_to_number(urgency), st.bug_name % (name, nickname, nickname, nickname)) @@ -465,6 +477,7 @@ for pkg in packages: pkg_name = None pkg_version = None +pkg_maintainers = [] pkg_arch = None pkg_source = None pkg_source_version = None @@ -473,6 +486,8 @@ pkg_name = contents elif name == Version: pkg_version = contents +elif name in
Bug#659843: security-tracker: add links to Ubuntu, Gentoo CVE trackers and to the openwall vendors page
On Thu, 2012-02-16 at 18:28 +0100, Florian Weimer wrote: Do you have an example of a working Gentoo cross-reference? https://bugs.gentoo.org/show_bug.cgi?id=CVE-2011-2183 -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#659843: security-tracker: add links to Ubuntu, Gentoo CVE trackers and to the openwall vendors page
tags 659843 + pending thanks On Wed, 2012-02-15 at 21:54 -0500, Michael Gilbert wrote: I just reviewed this. I say go ahead and apply it since its a straightforward duplication of the redhat url parsing. Applied. You'll need to sync the tracker code on soler before it goes live. I don't have access to soler.d.o since it is restricted. Hopefully someone will read this, update the code and close this bug. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#659843: security-tracker: add links to Ubuntu, Gentoo CVE trackers and to the openwall vendors page
Package: security-tracker
Severity: wishlist
Tags: patch
I would like to add the attached patch to the security tracker to add
links to the Ubuntu and Gentoo CVE trackers and add a link to the
openwall vendors page, which links to more trackers for more distros.
I have access to the security-tracker repository but I would like some
review of the patch and for someone to update the tracker website.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Index: bin/tracker_service.py
===
--- bin/tracker_service.py (revision 18427)
+++ bin/tracker_service.py (working copy)
@@ -313,6 +313,9 @@
; ,
self.make_rhbug_ref(url, bug.name,
'RH'),
+ self.make_ubuntu_bug_ref(url, bug.name, 'Ubuntu'),
+ self.make_gentoo_bug_ref(url, bug.name, 'Gentoo'),
+ A(url.absolute('http://oss-security.openwall.org/wiki/vendors'), 'more')
))
elif source == 'DSA':
source_xref = self.make_dsa_ref(url, bug.name, 'Debian')
@@ -1194,6 +1197,10 @@
def url_rhbug(self, url, name):
return url.absolute(https://bugzilla.redhat.com/show_bug.cgi;,
id=name)
+def url_ubuntu_bug(self, url, name):
+return url.absolute(http://people.canonical.com/~ubuntu-security/cve/%s; % name)
+def url_gentoo_bug(self, url, name):
+return url.absolute(http://bugs.gentoo.org/show_bug.cgi;, id=name)
def url_dsa(self, url, dsa, re_dsa=re.compile(r'^DSA-(\d+)(?:-\d+)?$')):
match = re_dsa.match(dsa)
@@ -1251,6 +1258,16 @@
name = cve
return A(self.url_rhbug(url, cve), name)
+def make_ubuntu_bug_ref(self, url, cve, name=None):
+if name is None:
+name = cve
+return A(self.url_ubuntu_bug(url, cve), name)
+
+def make_gentoo_bug_ref(self, url, cve, name=None):
+if name is None:
+name = cve
+return A(self.url_gentoo_bug(url, cve), name)
+
def make_dsa_ref(self, url, dsa, name=None):
if name is None:
name = dsa
signature.asc
Description: This is a digitally signed message part
