On Wed, 12 Jan 2022 11:11:42 +0100
Salvatore Bonaccorso wrote:
> Hi,
>
> On Wed, Jan 12, 2022 at 09:22:45AM +, Neil Williams wrote:
> > On Wed, 12 Jan 2022 12:44:14 +0800
> > Paul Wise wrote:
> >
> > > On Tue, 2022-01-11 at 11:20 +, 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
