Re: Getting new tracker service code to go live
On snein 3 Jannewaris 2010, Michael Gilbert wrote: I've updated the sql logic to workaround a bug in lenny's aspw (and the code is actually now a bit cleaner...for sql anyway). Please push this new commit to the live tracker. Ulib/python/security_db.py Updated to revision 13701. -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Getting new tracker service code to go live
On Sun, 03 Jan 2010 13:51:59 + security tracker role wrote: The error message was: Traceback (most recent call last): File bin/update-db, line 73, in module warnings = db.calculateVulnerabilities(cursor) File /srv/security-tracker.debian.org/website/secure-testing/lib/python/security_db.py, line 1159, in calculateVulnerabilities self._calcTesting(c, bug_name, 'oldstable', 'etch') File /srv/security-tracker.debian.org/website/secure-testing/lib/python/security_db.py, line 1288, in _calcTesting (bug_name, suite, status, pkgs)) File apsw.c, line 4238, in resetcursor apsw.ConstraintError: ConstraintError: constraint failed make: *** [all] Error 1 I can't reproduce this problem with the local tracker data that I have (on lenny or sid). My best guess is that there is a corner case in the live tracker where 'status' is not getting assigned, but I don't see the hole for that to happen. I've commited a fix that may resolve the issue. It may also be that the current database needs to be fully regenerated due to the new code. So maybe try deleting data/security.db and then running 'make all'. If not, can someone insert the following line above line 1285 in security_db.py and send me the output of 'make all' on the live tracker? print bug_name , suite , status , pkgs Thanks, Mike -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Getting new tracker service code to go live
Hi, * Michael Gilbert michael.s.gilb...@gmail.com [2010-01-03 19:20]: If someone can push the latest updates, I think I've solved the problem with the latest commit. I updated the tracker svn because I think your fix looks good. Apart from that... I know I haven't been very active recently, still I wonder why you need to implement undiscussed (excuse me if I missed this) tracker features and Thijs is blindly committing them. This is not how we should work in my opinion. Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 For security reasons, all text in this mail is double-rot13 encrypted. pgptY8Z6lGf2v.pgp Description: PGP signature
Re: Getting new tracker service code to go live
Hi, * Nico Golde n...@ngolde.de [2010-01-03 22:58]: * Michael Gilbert michael.s.gilb...@gmail.com [2010-01-03 19:20]: If someone can push the latest updates, I think I've solved the problem with the latest commit. I updated the tracker svn because I think your fix looks good. [...] Or not, I can't sudo into the sectracker account as I just updated my ldap password and it seems to take some time before it updates on soler... So if anyone is fast, please pull the trigger. Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 For security reasons, all text in this mail is double-rot13 encrypted. pgppTClnmvj6C.pgp Description: PGP signature
Documentation for the new undetermined tag
Hi all, I have implemented support for a new tag in the tracker called undetermined. The purpose of this tag is to describe the state of an issue that you are fairly certain applies to a specific package, but you have not had enough time (or there is not yet enough information) to be be confident in applying unfixed, fixed, or any of the other currently available statuses to the entry. This, for example, allows you to pass the burden on to the maintainer while also keeping track of it it. This is primarily intended for ill-defined, very new, and massive issues. If you are confident that an issue is fixed in a specific version, or that it is known unfixed, then undetermined wouldn't be the right status. Please continue to use the appropriate status when you have confidence in the state. If you know that an issue is fixed, but you don't know which specific version the fix is applied, you could also use undetermined, but that it should not be treated as a permanent state. You should come back and determine the fixed version. This tag creates a third status in the security tracker sqlite database, called undetermined. Previously there were only two valid statuses: vulnerable and fixed. For every CVE that has a source package with an undetermined tag, the tracker will now state that the status is undetermined for that source package and its associated binary packages on the CVE page. It will also state that the package may be vulnerable for each individual release where that is appropriate. If an urgency has not yet been specified in the CVE list, an undetermined urgency is automatically assigned, it is displayed normally with the entered urgency. For debsecan, undetermined issues are presently listed without an urgency (as if there issue were unfixed with no urgency included in the CVE list). This is not ideal, and should probably be improved in the future given the time to implement that. Any questions or feedback, please let me know. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Documentation for the new undetermined tag
On Sun, 3 Jan 2010 18:35:15 -0500 Michael Gilbert wrote: Any questions or feedback, please let me know. I forgot to mention that some issues are still being resolved, and while it is technically valid to use the new tag, it is not ready for prime-time. Please wait for more info before using it. Comments/feedback still welcome. Thanks, Mike -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
