[cut-team] Some experience with security support for testing

[Joey Hess]

Thanks for the background. Since my last real involvement with
secure-testing was somewhere around 2006, it's good to have more recent
details.

Stefan Fritsch wrote:
> Somewhere during Lenny's release cycle, all members of the testing 
> security team became also members of the stable security team. After 
> Lenny's release, there was more motivation to work on stable security, 
> and there were not many uploads to testing-security anymore. As you 
> may have noticed, there is more than enough work for stable.

So, I knew this happened, but I still don't fully understand *why* it
happened.

One hypothesis I have is that when I originally started the testing
security team in 2004, I did so with vague ideas of CUT in my head. The
whole point of working to secure testing was to make testing more
realistically usable. At the time we also had a significant CDD
(Skolelinux) making releases based on testing, and there were
semi-frequent d-i releases happening to install testing. 

What was lacking was any kind of a project-wide acceptance that getting
lots of users using testing, and doing a lot of work to support that,
both in security and otherwise, was a good idea. The point of the CUT
proposal was to develop that idea in the head of the project, but that
took time.

While that was going on, providing high-quality security support
specifically for testing was kind of a white elephant. It had few
obvious advantages, except around freezes, and the various technology
that the testing security team had developed (like the tracker) worked
just as well for helping with security support for stable. So,
naturally, there was a shift to focusing on security support for stable.

(Also, the testing security team's story about how fixes got into testing
was always a bit muddled -- as you mention, yeoman efforts to make lots
of special uploads could increase the total security of testing, but
only by a margin, as those fixes would get in anyway by normal means
eventually. And so, testing-security always spent a lot of effort
focusing on stuff like tracking CVEs, and filing bug reports, that
didn't look like traditional security support of a specific suite. And
could very easily be redirected into more generalized security support
of all suites, and then refocused back down to security support of
stable. And as that work continues, it *still* contributes significantly
to the security support of testing. Which is still not in the miserable
state the project, and public at large seem to expect.)

Does that all sound about right? If so, assuming that CUT actually happens,
it suggests that the existance of some testing-based thing with the 
project behind it and user interest, could in turn lead to renewed
interest in providing security support for testing, both from within and
without the current security team.

> I don't know what your current plans are, but having more than one 
> snapshot of testing with security support at the same time is 
> completely unrealistic.

Agreed, and thanks for pointing that out. It's a good invariant to keep
in mind.

-- 
see shy jo, who has taken the liberty of presering the CCs since I'm
            speculating about their motivations..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/cut-team/attachments/20100831/2dbbef7a/attachment.pgp>