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.