[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: improving the report-vuln script


Nice work. A single bug is quite useful when a lot of CVEs has been fixed in a single upstream release. Especially if they are of a similar nature.

/ Ola

Sent from a phone

Den 30 mar 2017 21:05 skrev "Antoine Beaupré" <anarcat@orangeseeds.org>:

I had some spare time today and I figured I would look at the backlog of
unreported vulnerabilities here:


This is one of the housekeeping tasks we were told was useful for the
security team here:


The instructions for using the report-vuln script weren't quite
accurate: first it can't really be used with reportbug, from what I can
tell, at least not in a useful way.. Reportbug will still prompt for all
its usual stuff which makes it less effective.

Furthermore, the recommended use (in the script itself) of Mutt doesn't
add the necessary headers, and I found the "blanks" argument rather

Therefore, I have rewritten parts of the script to make it easier to
automate. It's now possible to specify the severity and affected
versions directly on the commandline, and the usage is much clearer.


$ ./bin/report-vuln -h
./bin/report-vuln [--no-blanks] <pkg> <cve id(s)>


usage: report-vuln [-h] [--no-blanks] [--affected AFFECTED]
                   [--severity SEVERITY] [--no-cc] [--cc-list CCLIST]
                   pkg cve [cve ...]

positional arguments:
  pkg                   affected package
  cve                   relevant CVE for this issue, may be used multiple time
                        if the issue has multiple CVEs

optional arguments:
  -h, --help            show this help message and exit
  --no-blanks, --blanks
                        include blank fields to be filled (default: False)
  --affected AFFECTED   affected version (default: unspecified)
  --severity SEVERITY   severity (default: grave)
  --no-cc, --cc         add X-Debbugs-CC header to
  --cc-list CCLIST      list of addres to add in CC (default:
                        ['team@security.debian.org', 'secure-testing-

I was not sure in which case multiple CVEs could be used - should we
report multiple CVEs in a single bug? that seems like bad
practice... IMHO, each bug should have its own CVE...

Ideally, this script would interactively submit the bug and wait for
confirmation, but it seems this is something that is notoriously hard to
do in the Debian BTS - I personnally haven't found a way to promptly get
a bug identifier when submitting bugs other than waiting for the
autoreply to kick in, which can take some time.

Since this is not something the LTS team directly uses all the time -
it's more something for the main security team - I figured it would be
safer to submit it for review here, especially since the changes are
rather large. Let me know if there's a better place to discuss this if
this isn't appropriate.

Attached is the patch for the new features and a fresh copy which is
only twice as long as the diff...


Worker bees can leave
Even drones can fly away
The queeen is their slave
                        - Fight Club

Reply to: