Debconf 2017 LTS BoF Summary
Hi,
here's a short summary from the BoF;
* A internal review of the first commits to the security-tracker for new
LTS team members by other LTS team members would be good.
IMHO we should just do that.
* The Security team requests help with keeping the list at
https://security-tracker.debian.org/tracker/status/unreported
down. Got better during the last year for new packages but there's
still a backlog. That's an recurring topic from last year.
* For temp issues request CVEs (http://cve.mitre.org/cve/request_id.html).
Mark status in the tracker to avoid duplication.
Backlog: https://security-tracker.debian.org/tracker/data/fake-names
* BTS is the canonical place for communication about the bug so the idea
is to change bin/contact-maintainer to use the BTS this would avoid
double communication from security and lts team (and maybe also avoid
the maintainers from feeling pushed like we had in the past). Are
there any objections?
* We should try to track regressions to security updates more automatically
Alternatively
- the stable report-bug could offer to cc: the lts team on
issues if filed against the corresponding release and version
is a security update version (same for stable if wanted)
- query UDD (blend script does something like that, Andreas Tille
wrote it, see
https://anonscm.debian.org/cgit/blends/website.git/tree/webtools/bugs.py)
both ways seem worth exploring.
* Rules the security team uses for bug severities filed by
bin/report-vuln: early in the release -> RC, later depending on
severity of CVE - in doubt start high.
* D{S,L}A texts are hand written. Copying texts from other distros,
websites might be problematic due to license so better rewrite from
scratch (which largely rules out further automation). The CVE number
links to all the details so the type of severity (and attribution if
found) is enough, the rest can be found by interested people on the
web.
* A staging repository on security-master (similar to proposed-updates
for stable releases) would be great since it would do away with
copying to people.d.o, etc.
It would allow people with CI to test packages before they hit
production. It also makes it simple to point "known testers" of
certain types of packages to test them and would hopefully make
more people test updates since they appear at a stable URL. Discussion
on this will continue.
Gobby text is at [1] and attached. Thanks to everybody for their
input. Please post corrections if I missed or misunderstood something.
Cheers,
-- Guido
[1]: https://gobby.debian.org/export/debconf17/bof/lts-and-security-team-bof
LTS and Security Team BoF
=========================
* A internal review of the first commits to the security-tracker for new
LTS team members would be good.
* Security team requests help with keeping the list at
https://security-tracker.debian.org/tracker/status/unreported
down. Got better during the last year for new packages.
* For temp issues request CVE (http://cve.mitre.org/cve/request_id.html).
Mark status in the tracker to avoid duplication.
Backlog: https://security-tracker.debian.org/tracker/data/fake-names
* BTS is the canonical place for communication about the bug
- Version information there is not up-to-date and that is ok <- security
tracker is canonical for that
Should we skip our LTS "do you want to take care of this yourself"
mails and rely on the BTS completely?
* Try to keep inter distro info up-to-date (link???)
* To track regressions after an upload track the BTS for one/two weeks after
a release.
Alternatively
- the stable report-bug could query for security
regressions and puth the lists in cc.
- query UDD (blend script does something like that, Andreas Tille
wrote it, see
https://anonscm.debian.org/cgit/blends/website.git/tree/webtools/bugs.py
* cacti has a autopkgtest that includes exploits test
(test suite works with tweaks for older verions)
* bin/check-new-issues (command) in secure-testing helps with new issues.
Some emacs integration for d{l,s}a-needed and data/CVE/list but that
can be improved.
* there was/is a connection with the bts: CVE usertag or tag. Details anyone?
* severity of bugs: early in the release -> RC, later depending on severity of CVE
- in doubt start high
* license of CVE text is unclear -> Moritz rewrites from scratch
- generic description of the issue instead of details of functions
* s.th. like proposed-updates (a staging repository) for security would be
great for stable and lts since it would do away with "please test ..." and
allows people with CI to test packages before they hit production. It all
so makes it simple to point "known testers" of certain types of packages
to it.
Reply to: