On Wed, 12 Jan 2022 11:11:42 +0100 Salvatore Bonaccorso <carnil@debian.org> wrote: > Hi, > > On Wed, Jan 12, 2022 at 09:22:45AM +0000, Neil Williams wrote: > > On Wed, 12 Jan 2022 12:44:14 +0800 > > Paul Wise <pabs@debian.org> wrote: > > > > > On Tue, 2022-01-11 at 11:20 +0000, Neil Williams wrote: > > > > > > > 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.) > > > > > > FTR, lintian does not do any network requests, so this approach > > > won't be accepted. The best option you can get is a script to do > > > the download at the lintian release time. Unfortunately this > > > means the data will get outdated quickly and make the check less > > > useful. > > > > > > This check could be added to devscripts, debsecan or duck. > > > > debsecan looks promising. It already has support for reporting a > > list of CVEs by source_package name, directly from > > https://security-tracker.debian.org/tracker/ and it's Python3. I'll > > have a look at a patch which accepts a .changes file or d.changelog > > entry and verifies if all listed CVEs actually exist for the source > > package of that change. > > To jump in in that part of the discussion: debsecan's scope is > different what we want to tackle here. Its a tool which is used on > user systems to generate a list of vulnerabilities which affect the > installed Debian system, gathering data from the security-tracker and > comparing on what is installed. True, so a patch directly to debsecan isn't the best option. However, debsecan does have an API for the network operation needed for a developer to download specific security tracker data without needing to get the entire JSON. This is the bit that can't go into lintian & debsecan's API is fast. This API allows a new script that uses the some of that debsecan code and some of the grab-cve-in-fix code to parse a .changes file on STDIN, extract the CVEs which the maintainer claims will be closed by that upload and verify that the CVE numbers exist in the current security tracker, at the time of running the script, for the source package and new version string that are specified in the changes file. It can do this needing only python3-apt and python3-debian, without needing to import Python code or local data files from the security tracker git tree. i.e. the code in debsecan gets me to a proof-of-concept for such a script that works, as below (using a modified .changes file copied from https://tracker.debian.org/news/1291853/accepted-vim-2823995-1-source-into-unstable/ that deliberately includes the typo from that epiphany test we've used before). initial PoC output: CVE-2021-3984 is already fixed in vim CVE-2022-0158 in vim will be closed by this upload CVE-2022-0156 in vim will be closed by this upload CVE-2021-4508 is not an open CVE in vim So I can then remove the unwanted parts of this PoC and create a new script, derived from debsecan, that could go into devscripts or similar. We should discuss this "abuse"/re-use of the debsecan support in https://security-tracker.debian.org/tracker/ and whether to clone that support for a new script - no changes would be needed in the security tracker code other than possibly a change in User-Agent & the debsecan part of the URL. Let me know your preference for: 1. re-use the debsecan API without changes 2. clone the debsecan API in security-tracker with minimal changes (UserAgent, URL & Version only) - the code would use precisely the same DB tables as debsecan. Tested locally with http://127.0.0.1:10605/tracker/debsecan/release/1/ - the script works in under half a second. I can then file a new bug in devscripts for a new script (check-cve-upload? or cvecheck?), complete with an initial PoC. It's possible that some of this common code in cvecheck & grab-cve-in-fix could go into python3-debian but the PoC only needs to add 43 lines to debsecan, so it might not be worth it. The guts of it is just comparing two lists that are already available from the current scripts. What's in the changes list but not in the debsecan list is not a CVE that should be mentioned by the upload. These are the typos we're trying to find, so report an error & exit non-zero. What's in the debsecan list but not in the changes list is a CVE that will remain open after the upload. These the maintainer should know about in case something has been omitted, so report a warning & exit non-zero. What is in the changes list and in debsecan list *but as already fixed* according to debsecan is a warning that can be caught this way, so report & exit non-zero. What's left in both should be a correct fix via that upload, exit zero. -- Neil Williams ============= https://linux.codehelp.co.uk/
Attachment:
pgpSdvZS2Tqt7.pgp
Description: OpenPGP digital signature