[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [all candidates] Advertising testing and security support


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
- 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 

> 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:
No special privileges are needed to start, and commit access to our repository 
is quickly handed out.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: