Hi Salvatore, On Mon, 20 Dec 2021 12:30:36 +0100 Salvatore Bonaccorso <carnil@debian.org> 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/
Attachment:
pgpCE4lCNapTy.pgp
Description: OpenPGP digital signature