Hi 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é" <anar...@orangeseeds.org>: > Hi, > > I had some spare time today and I figured I would look at the backlog of > unreported vulnerabilities here: > > https://security-tracker.debian.org/tracker/status/unreported > > This is one of the housekeeping tasks we were told was useful for the > security team here: > > https://wiki.debian.org/LTS/Development#Housekeeping_Tasks > > 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 > confusing. > > 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. > > Before: > > $ ./bin/report-vuln -h > ./bin/report-vuln [--no-blanks] <pkg> <cve id(s)> > > Now: > > 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: > ['t...@security.debian.org', 'secure-testing- > t...@lists.alioth.debian.org']) > > 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... > > > > A. > > -- > Worker bees can leave > Even drones can fly away > The queeen is their slave > - Fight Club > >
