External check
CVE-2021-23727: TODO: check -- The output might be a bit terse, but the above ids are known elsewhere, check the references in the tracker. The second part indicates the status of that id in the tracker at the moment the script was run.
Bug#1001453: security-tracker: extend support for bug reporting to update the CVE list with the bug number
On Fri, 17 Dec 2021 13:56:26 + Neil Williams wrote: > On Fri, 10 Dec 2021 10:56:25 + Neil Williams > wrote: > > A tool to automate a syntactically correct change to a specific CVE > > would be a useful extension of this support, not just to add the bug > > number once the email is received from the BTS but to also make other > > standard changes: > > > > - mark a given released suite (stable/oldstable/LTS) as > > For this operation, should clear only specific kinds for > the specified suite? > > e.g. if kind==fixed, then version would need to be unset for the CVE to > show as not-affected & any bug number might also have to be cleared if > the suite was specified as sid? > > Should annotations like "Minor issue" be retained or removed? > > Or should the script refuse to change kind==fixed & possibly others & > maybe only make changes if kind is None? > Candidate bin/update-vuln script is now in my fork on Salsa: https://salsa.debian.org/codehelp/security-tracker/-/blob/grabcvefix/bin/update-vuln https://salsa.debian.org/codehelp/security-tracker/-/raw/grabcvefix/bin/update-vuln As noted in the script: Only make one change to one CVE at a time. Review and merge that change and delete the merged file before updating the same CVE. The workflow would be: ./bin/update-vuln --cve CVE--N ... # on exit zero: ./bin/merge-cve-files ./CVE--N.list # review change to data/CVE/list git diff data/CVE/list rm ./CVE--N.list # .. step and repeat git add data/CVE/list git commit As with #1001451 and grab-cve-in-fix, the code may yet need to move into lib.python.sectracker to be properly tested. Also, the change in #1001451 for merge-cve-files is also needed for the update-vuln support. Note the addition of the --description option for support - that will typically require quoting the argument. e.g. $ ./bin/update-vuln --cve CVE--N --src --suite buster --description "Vulnerable code introduced later" $ ./bin/update-vuln --help usage: update-vuln [-h] --cve CVE [--src SRC --suite SUITE [--description DESCRIPTION]] | [[--number NUMBER] [--itp SRC]] | [--note NOTE] Make a single update to specified CVE data as not-affected, add bug number or add a note optional arguments: -h, --helpshow this help message and exit Required arguments: --cve CVE The CVE ID to update Marking a CVE as not-affected - must use --src and --suite Optionally add a description or omit to remove the current description: --src SRC Source package name in SUITE --suite SUITE Mark the CVE as in SUITE --description DESCRIPTION Optional description of why the SRC is unaffected in SUITE Add a bug number to the CVE: --number NUMBER Debian BTS bug number --itp SRC Mark as an ITP bug for the specified source package name Add a NOTE: entry to the CVE: --note NOTE Content of the NOTE: entry to add to the CVE Data is written to a new .list file which can be used with './bin/merge-cve-files'. Make sure the output file is merged and removed before updating the same CVE again. -- Neil Williams = https://linux.codehelp.co.uk/ pgpHyWc6dfWiw.pgp Description: OpenPGP digital signature
Bug#1001451: Candidate script updates
Hi Salvatore, On Mon, 20 Dec 2021 12:30:36 +0100 Salvatore Bonaccorso wrote: > Hi Neil, > > Btw, if you want "real" cases why not to do automatic merges: > https://tracker.debian.org/news/1287752/accepted-epiphany-browser-412-1-source-into-unstable/ > typo in CVE, and > https://tracker.debian.org/news/1287534/accepted-bluez-562-1-source-into-unstable/ > where one CVE was actually not really fixed. 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. Should the script also advise that a (normal|minor) bug is filed against the source-package to fix the d.changelog (retrospectively or in the next changelog entry?) or is it sufficient that the security-tracker has the correct information? For the bluez case, the 5.62-1 upload would update both CVEs. My expectation is that finding out that CVE-2021-41229 was not fixed would result in a separate change to data/CVE/list to remove the fixed version of 5.62-1. Then when 5.62-2 as uploaded, CVE-2021-41229 would be marked as fixed in 5.62-2 as normal. In case a separate change is not made to data/CVE/list, I've adjusted the script so that if the fix version is older than the version from the retrieved changes entry, the CVE is updated to show the newer version. i.e. 5.62-1 would be changed to 5.62-2. This introduces a dependency on python3-apt to be able to get the correct version comparison support, hopefully that is OK. (python3-debian doesn't have dpkg --compare-versions type support.) 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. 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? https://salsa.debian.org/codehelp/security-tracker/-/tree/grabcvefix https://salsa.debian.org/codehelp/security-tracker/-/blob/grabcvefix/bin/grab-cve-in-fix https://salsa.debian.org/codehelp/security-tracker/-/raw/grabcvefix/bin/grab-cve-in-fix https://salsa.debian.org/codehelp/security-tracker/-/blob/grabcvefix/bin/merge-cve-files -- Neil Williams = https://linux.codehelp.co.uk/ pgpbxNC8aquUR.pgp Description: OpenPGP digital signature
