Hi, Now that all candidates have had their chance for comment, let me just take the liberty to add my views to this. Op dinsdag 19 maart 2013 23:52:57 schreef Jérémy Bobbio: > Even if a dedicated team is supposed to care about security in > testing [1], the dedicated mailing-list [2] has not seen an announcement > since February 2011. > > Dear candidates, do you think it would be wise to advertise `testing` as > a usable distribution to our users given that state of affairs? Given > that our security support for stable is already not as best as it could > be, do you think we should encourage volunteers to be more active in > security support for testing? Do you have ideas on how to attract more > volunteers to the dull, hard, and sometimes boring tasks of taking care > of security issues in Debian? It is true that the debian-testing-security-announce mailinglist has not been used in the wheezy timeframe. However, this should not be a measure of the state of security in this distribution. As always with testing, uploads through unstable are the best way to fix problems in testing and the security team uses this extensively to ensure that fixes end up in wheezy quickly: ensuring the correct urgency, asking the RT to bump it where necessary, and, when frozen, making sure the proper unblocks are in place or to go through testing-proposed-updates. I'm not sure it's possible to say which of our releases is in practice the most secure, considering the following: - Of course, stable always has the top priority for the security team. However, in practice it's hardly ever necessary to make an explicit choice here and fixing of the various releases happens in parallel. - For embargoed issues, we can prepare and stage updates for stable, with all archs already built at time of release. For unstable, building starts with the first public upload. The number of embargoed issues is however very low. - Fixing unstable and testing can often be done relatively quickly, by 'just' uploading a new upstream release, while for stable oftentimes more backporting effort is involved. Therefore, uploading to unstable happens while the stable update is in preparation - this allows the fix to get tested already and the package to age for migration. You could say that on average, unstable gets its security fixes the most quickly. - On the other hand, a significant number of the discovered issues only affect newer versions of software. The "given enough eyes" principle applies, and often the version in stable doesn't suffer from security issues that were newly introduced in relatively new code in testing and unstable. All in all these interactions make it quite a murky business to decide which distribution is the "most secure". I think sticking to describing the facts is best, and I think we should be able to state that we have an active security team that watches over the security of all our releases, from oldstable to unstable. > And according to the tracker, there's close to 100 > packages with open issues in stable at the moment: > <https://security-tracker.debian.org/tracker/status/release/stable>. As you already noted, given that we have tens of thousands of packages, and the continuous infux of newly discovered issues every day, I'm not surprised that we have 100 open 'issues' at any one time. However, that an issue is open doesn't say anything really about its severity or urgency (the 'Urgency' field in that table is sourced automatically from NVD and not assessed in a Debian context). In any case, issues in the "remote root" category are very rare, and quickly fixed. We can always use more hands to reduce the list even further and respond even quicker. Our procedures are documented, and we always refer new people to this page as the starting point for contributing: https://security-tracker.debian.org/tracker/data/report No special privileges are needed to start, and commit access to our repository is quickly handed out. Cheers, Thijs
Attachment:
signature.asc
Description: This is a digitally signed message part.