Hi all, At a 'working lunch' during DebConf about security in Debian, we came up with the following bits and pieces. Hopefully this should help get a quicker and more efficient response to security in Debian.
Increase the visibility of testing security ------------------------------------------- It was pointed out (I think by me) that a lot of the work isn't visible, as it often involves making sure things get pushed through unstable, rather than issuing a DTSA. This is especially true at release time. One possibility would be to use debsecan to automatically work out what has been moved where, and generate reports based on this. However, the number of false positives, and email format of debsecan needs improvement before this can occur. More bugs should be filed against packages with open security vulnerabilities. It seems that the maintainers are often (somehow) unaware that their package has an open issue. For unstable fixes, we should just NMU with no delay or notification (making sure that it's just the security fix though) to ensure that migration can start to happen as soon as possible. How to improve the tracker[0] ----------------------------- Public submission to the tracker would help a lot, we lack the current man-power to effectively track everything. Part of the problem involved with this is the way the advisory and code system is in the same repository as the tracking data. This should be split up. It would be nice if the tracker data was somehow integrated with the PTS as well. How to get maintainers to help us --------------------------------- It seems that maintainers are a little confused as to what should happen if there's a security issue, mostly due to the documentation being out of date in various places (dev-ref etc). It was also pointed out that the vast majority of security uploads should be done with a high priority. See [Documentation] below. An additional NM question could be introduced, along the lines of "How long should you support your package for security issues?" as some maintainers seem to be resistant to fixing bugs in their packages that no longer exist in unstable. Lenny plans ----------- Some packages were released with etch that are very hard to support by the SST. It would be good to try and avoid these getting into testing or even unstable all together. Embedded code copies are still causing problems. There's a policy bug open (http://bugs.debian.org/392362), and Neil McGovern will ask the RMs to make 'no embedded code copies' a release goal. Documentation ------------- Documentation should be written/updated for the following groups: Maintainers: how to be nice to the security team. Tracker submitters: how to help us (one for DDs, and one for non-DDs). dev-ref: it could do with a lot of improvement to reflect current practice. A 'bits from the security team' to d-d-a may be useful once this is done. Disto agnostic patch/tracking/magic system/conference/mad-idea -------------------------------------------------------------- A mad idea was formed to look at the possibility of creating a more harmonised approach to security in Linux generally. A patch repository and/or tracking system that could be used for all distributions may be useful. This may help create a more unified approach to security, and stop work being duplicated. Additionally, a global Linux distro security teams summit may be something that would help kick-start this approach. I think this is fairly accurate. Any comments? Cheers, Neil [0] http://security-tracker.debian.net/ -- <hermanr> 10 people enough for a Debconf? If they were all Germans, maybe...
signature.asc
Description: Digital signature
_______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
