Hi! In the weekend 14-16 January 2011, the Debian Security Team convened in Linux Hotel, Essen. We discussed many things, a lot of security work was done and of course the necessary socialising wasn't forgotten. We'd like to thank the Linux Hotel for again receiving us in such a great way! What follows is a high level summary of things discussed and of general interest. Don't forget to read our call for volunteers at the end! ;-) * Improvements to the team workflow Lots of discussion was dedicated to various aspects of improving the team workflow. An important conclusion is that each week one team member will be a "front desk", ensuring that all incoming communications and issues are properly tracked and followed up upon. Others can then concentrate on the actual fixing of those issues. The team has been making use of Debian's Request Tracker for a longer while now, but we want to encourage maintainers contacting us about issues to file them there directly.[1] We will update our documentation for that. Since a couple of years we've been handing off security issues of minor or theoretical impact but for which a fix would be desirable at some point, like certain classes of denial-of-service attacks, off to stable point updates. We're looking for a person that wants to coordinate this: monitor the Security Tracker for issues classified as such by the Security Team, converse with maintainers to get such updates done and coordinate with the stable release managers on this. Since no upload privileges are involved you don't even need to be a DD. The DSA release process itself has been redesigned from the ground up, in order to eliminate as much as possible of the current manual work that needs to be done for each advisory. Also we evaluated which information we do and do not want to publish for an advisory. This includes a new way to generate the advisory information, which will also allow for better machine parsable formats, automatic signing of build logs and many wishlist items for the Security Tracker. This bit still requires significant implementation work though. This we hope to implement in the next months. It will also allow the implementation of more advanced exports, like the generation of OVAL signatures. * Hardening compiler flags Debian is currently one of the few distributions that doesn't enable hardening options in the compiler that protect packages against certain types of vulnerability. There has been work on this for a longer time but it didn't yet come to fruition. A Birds of a Feather-session will be organised at the upcoming Debian Conference to get all involved people together and implement this. * Longer security support for Debian stable Current Debian releases are supported for a year after the next version has been released; this tends to come down to around three years in recent times. There has been some interest to have Debian stable security supported for a longer period of time, say five years. We've explored what conditions such support should fulfil, but more discussion needs to happen before it can become a reality. * "Beta testing" of security updates A past Google Summer of Code project was targeted at providing non-embargoed but still pending security updates already to a select group of "beta testers" (e.g. test environments in corporate setups) to get early feedback in case of breakage. Unfortunately this hasn't been realised until now, but we're still pushing the idea. * README.test Although many packages include a test suite that is run after package build, there are packages that do not have such a suite, or not one that can be run as part of the build process. It was proposed to standardise on a README.test file, analogous to README.source, describing to others than the regular maintainer how the package's functionality can properly be tested. This is something we would like to see discussed and implemented for the Wheezy development cycle. * Backports security support Gerfried Fuchs was invited to the meeting to discuss the security support of backports.debian.org. Gerfried is mostly the only one working on this. Some backporters don't track the status of their backports regularly and thus have outstanding security fixes. It is needed to raise awareness of the status page in the Security Tracker for backporters: http://security-tracker.debian.org/tracker/status/release/stable-backports Help with backports security support would be welcome. * Issues in specific packages We further discussed some specific problematic packages. One example is ia32-libs, which is difficult because it includes 100+ other source packages. This will be handled better for Squeeze: we'll have to ensure it's as up to date as possible at time of release, and will keep updating it in stable point updates to include newer package versions from the security archive (or the stable release itself). For some packages it's difficult for the Security Team to set up a representative test environment, like hardware-specific VoIP applications or complex web applications. We're exploring technical possibilities to open up the security update process so that maintainers of such packages are more deeply involved in releasing security updates for these packages. * Call for volunteers This is where we need you! :-) If you've read this far, chances are that you're probably interested in what we do. Why not join us? There are several ways: - Become stable-point-update-candidates coordinator (see above). Coordinate less severe security updates with maintainers, stable release management and of course the rest of the security team. - Help out with security for backports.debian.org. Mostly this involves backporting newer package versions that include security fixes. Contact Gerfried Fuchs if interested. - Are you following bugtraq, oss-security and other security news? Want to become a member of the security team? A great way to start is to work on our Security Tracker. Most current members of the Security Team started this way into the team and you could be next. Classify incoming issues, ensure issues from mailing lists are properly filed and prepare updates for vulnerabilities that are already public. See our introduction on how to start: http://svn.debian.org/wsvn/secure-testing/doc/narrative_introduction and join us on irc.debian.org #debian-security. The full minutes of the meeting can be found via: http://wiki.debian.org/DebianSecurity/Meetings/2011-01-14 On behalf of the Security Team, Thijs Kinkhorst [1] http://wiki.debian.org/rt.debian.org#SecurityTeam
Attachment:
signature.asc
Description: This is a digitally signed message part.