Bug#1001451: Candidate script

[Salvatore Bonaccorso <carnil@debian.org>]

Hi Neil,

On Fri, Dec 17, 2021 at 01:22:32PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Fri, Dec 17, 2021 at 11:57:34AM +0000, Neil Williams wrote:
> > https://salsa.debian.org/codehelp/security-tracker/-/commit/2df53b5421cde0c7b1b2dd3343d71aebde2d55b7
> > 
> > https://salsa.debian.org/codehelp/security-tracker/-/raw/grabcvefix/bin/grab-cve-in-fix
> > 
> > Dependencies: python3-debian
> > 
> > Usage: Download from the raw link as bin/grab-cve-in-fix and make it executable.
> > 
> > ./bin/grab-cve-in-fix --help
> > 
> > usage: grab-cve-in-fix [-h] [[--email EMAIL] | [--tracker TRACKER]] | [[--src SRC] & [--cves [CVES ...]]]
> > 
> > Grab CVE data from a package upload for manual review
> > 
> > optional arguments:
> >   -h, --help         show this help message and exit
> > 
> > Online - query either the distro-tracker or debian-devel-changes mail archive:
> >   --email EMAIL      URL of debian-devel-changes announcement in the list archive
> >   --tracker TRACKER  URL of tracker.debian.org 'Accepted NEWS' page for unstable
> > 
> > Offline - run 'make update-packages' first & specify source package and CVE list:
> >   --src SRC          Source package name to look up version in local packages files
> >   --cves [CVES ...]  CVE ID tag with version from local packages files
> > 
> > Data is written to a new <source_package>.list file which can be used with './bin/merge-cve-files'
> > 
> > 
> > Examples:
> > 
> > ./bin/grab-cve-in-fix --src freerdp2 --cve CVE-2021-41160
> > 
> > ./bin/grab-cve-in-fix --tracker https://tracker.debian.org/news/1285227/accepted-freerdp2-241dfsg1-1-source-into-unstable/
> > 
> > ./bin/grab-cve-in-fix --email https://lists.debian.org/debian-devel-changes/2021/12/msg01280.html
> > 
> > (For these specific examples, data/CVE/list for CVE-2021-41160 would need to be altered, say to <unfixed>, locally.)
> 
> Nice! I will need (or want) to try to experiment with it a bit on
> apparing real cases.

Just doing a quick test, while beeing entusiastic about your proposed
script: I think it will not work correctly yet wit bin/merge-cve-list.
On either side it will need adaption.

Taking the example with freerdp2, assuming there won't be the fixed
version yet in the data/CVE/list it will produce the following
freerdp2.list:

CVE-2021-41160 (FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), ...)
        - freerdp2 2.4.1+dfsg1-1 (bug #1001062)
        [bullseye] - freerdp2 <no-dsa> (Minor issue)
        [buster] - freerdp2 <no-dsa> (Minor issue)
        - freerdp <removed>
        [stretch] - freerdp <no-dsa> (Minor issue)
        NOTE: https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-7c9r-6r2q-93qg
        NOTE: https://github.com/FreeRDP/FreeRDP/pull/7349
        NOTE: https://github.com/FreeRDP/FreeRDP/commit/217e0caa181fc1690cf84dd6a3ba1a4f90c02692
CVE-2021-41159 (FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), ...)
        - freerdp2 2.4.1+dfsg1-1 (bug #1001061)
        [bullseye] - freerdp2 <no-dsa> (Minor issue)
        [buster] - freerdp2 <no-dsa> (Minor issue)
        - freerdp <removed>
        [stretch] - freerdp <no-dsa> (Minor issue)
        NOTE: https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-vh34-m9h7-95xq
        NOTE: https://github.com/FreeRDP/FreeRDP/commit/d39a7ba5c38e3ba3b99b1558dc2ab0970cbfb0c5 (Stable 2.0 backports)
        NOTE: https://github.com/FreeRDP/FreeRDP/commit/f0b44da67c09488178000725ff9f2729ccfdf9fe

which one would then manually review first. But ideally the NOTE's are
not handled by the merge-cve-list script. So either your proposed
script can strip the NOTEs, or one does it manually, or
bin/merge-cve-lists can deal with that situation.

$ ./bin/merge-cve-list data/CVE/list ./freerdp2.list
[...]
NotImplementedError: unsupported annotation of type NOTE (line 7)

So maybe it's just merge-cve-list which should be better and allow for
such situation and handle as well the NOTEs.

This just what i noticed while wanting to try it out.

Usually we read the debian-changes mails in a MUA, so I wonder if we
can make the script accept as well not only things passed by --tracker
or --email, but rather piped trough when reading the changes mail in
e.g. mutt. What woud you think about it?

Regards,
Salvatore