Hi Salvatore, On Mon, 10 Jan 2022 17:10:15 +0100 Salvatore Bonaccorso <carnil@debian.org> wrote: > > So for that epiphany tracker, there is a typo in the d.changelog - > > the automated link for CVE-2021-4508 is a 404. > > > > I've updated the script to catch this and report the error. From the > > security-tracker source-package page for epiphany, it looks like the > > d.changelog entry should be CVE-2021-45088 - a simple typo to omit > > the final repeated digit. > > > > Currently, I'm handling this by advising that the script is re-run > > using the offline support and a corrected list of CVE IDs. > > > > This also adds a --force-version option to the offline support, in > > case sid has moved ahead of the fixed version by the time the CVE > > list is updated. > > Ack, this works indeed in this case as the CVE-2021-4508 does not > exist (yet). But in other cases typos are e.g. just wapping a number > or misstype the year, or other typos, which lead to an existing CVE. > So basically this all really boils down to, people working on > security-tracker trying as much as possible, in the human limits :), > to do a diligent work as possible. The script also prints out the CVE description and then tries to identify any existing package link by checking the PackageAnnotation of each CVE. It prints a warning if the source package of the CVE from the changes input doesn't match the source package of the changes itself or the source package(s) of other CVEs in the list. It can't always be an error as the situation with embedded copies & removed|reintroduced packages makes it hard for the script. However, it should be obvious from the output if a typo has been made. I've also added output if a typo matches a CVE that is an NFU as there are lot more of those in data/CVE/list e.g. $ cat test.changes| ./bin/grab-cve-in-fix --input grab-cve-in-fix - INFO - Retrieving data STDIN ... grab-cve-in-fix - INFO - CVE-2021-45085: (XSS can occur in GNOME Web (aka Epiphany) before 40.4 and 41.x before ...) grab-cve-in-fix - INFO - CVE-2021-45086: (XSS can occur in GNOME Web (aka Epiphany) before 40.4 and 41.x before ...) grab-cve-in-fix - INFO - CVE-2021-45087: (XSS can occur in GNOME Web (aka Epiphany) before 40.4 and 41.x before ...) grab-cve-in-fix - INFO - CVE-2021-3757: (immer is vulnerable to Improperly Controlled Modification of Object Pr ...) grab-cve-in-fix - ERROR - CVE CVE-2021-3757 is not attributed to a Debian package: ['NOT-FOR-US', 'NOTE'] (test.changes in this case was edited to change the typo to CVE-2021-3757 to demonstrate the output). 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.) > But if you spot an easy or obvious to detect case which the script can > warn of, then this can be helpful! After all you are trying to write > up scripts which should help the workflow. > > > It's hard to see how to best test these scripts properly on an > > ongoing basis. The "correct" output of each script depends entirely > > on the current state of data/CVE/list and the setup_paths support > > gets in the way of using a static CVE list in a test directory. > > > > I yet may push all of the non-argparse code into a > > lib.python.sectracker module to at least have some way to test > > individual functions with carefully mangled static copies of > > data/CVE/list content. > > In general I would find it perfect if we can have a sort of testsuite > or CI for the code part indeed of the security-tracker. In fact the > situation now without any tests has potential for many breackages when > one want to fix something, as the code has grown over decades almost > :). If you have a solution for that, and if splittiong out code into > libs can help, then that would be a welcome improvmenet. OK, I had looked at the lib/python/sectracker_test directory but the tests failed after trying to find lenny apt sources & then failed again when I changed that to something current.... I'll work on CI that can run in Salsa & hopefully will be easier to keep up to date. > (Note: I expect that the security-tracker will need some refactoring > in the 2022 year, as MITRE will change e.g. how data is exported and > which formats are supported, in particular this will affect our > automatic update scripts currently relying on downloading the > allitmes.html file, where it's planned now that this will change and > there will be only a JSON export of the data, we will need to adapt > the security-tracker on that regard, and possibly you will be > interested here :)) > > > For now, I'll mirror the real changes in data/CVE/list, trying to > > use the scripts to make some of the same changes. (Not all > > operations on data/CVE/list are to be covered.) > > > > Should bin/merge-cve-files also clean up the .xpck files that are > > created? On success only? > > Will be good to not have them lying around afterwards yes. I'll fix that. -- Neil Williams ============= https://linux.codehelp.co.uk/
Attachment:
pgpAaQG__Tq0F.pgp
Description: OpenPGP digital signature