Author: fw
Date: 2005-12-23 22:35:45 +0000 (Fri, 23 Dec 2005)
New Revision: 3145
Modified:
lib/python/security_db.py
Log:
lib/python/security_db.py (DB.calculateDebsecan1):
Existence of a release-specific fix means that sid was vulnerable at
some point (this is central to our tracking model).
Modified: lib/python/security_db.py
===================================================================
--- lib/python/security_db.py 2005-12-23 22:24:50 UTC (rev 3144)
+++ lib/python/security_db.py 2005-12-23 22:35:45 UTC (rev 3145)
@@ -1406,7 +1406,16 @@
GROUP BY package, bug_name
ORDER BY package, bug_name""")):
- unstable_fixed = '0'
+ # By default, unstable is unfixed even if there are
+ # only release-specific annotations available. This
+ # is slightly at odds with the web front end (see
+ # data/latently-vulnerable) which does not normally
+ # report unstable versions as vulnerable in this case.
+ # However, in our tracking model, the main branch
+ # (sid) cannot be non-vulnerable, while the
+ # release-specific branches are.
+ unstable_fixed = ''
+
total_urgency = ''
other_versions = {}
is_binary = False
@@ -1472,10 +1481,11 @@
if not total_urgency:
total_urgency = 'unknown'
- # Check if the issue does not actually mark any packages
- # as vulnerable.
- if total_urgency == 'unimportant' \
- or (unstable_fixed == '0' and len(other_versions) == 0):
+ # Check if the issue does not actually mark any
+ # packages as vulnerable. (If unstable_fixed == '0',
+ # release-specific annotations cannot create
+ # vulnerabilities, either.)
+ if total_urgency == 'unimportant' or unstable_fixed == '0':
continue
if unstable_fixed is None:
_______________________________________________
Secure-testing-commits mailing list
Secure-testing-commits@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/secure-testing-commits
