Re: security in testing
On Fri, May 16, 2003 at 10:40:10AM +1000, Anthony Towns wrote:
> On Thu, May 15, 2003 at 10:06:47AM -0400, Matt Zimmerman wrote:
> > There's that "we" again. Why not unstable, too?
>
> I'd have no problem with that.
You don't seem to have any problem suggesting that other people do more
work.
> So automate it more. Throw more people at it. Distribute it more. You've
> currently got five people on the security team, at least three of which
> are splitting their time between that and other fairly major Debian
> projects; it is, afaik, almost impossible for non-security team members to
> either know which DSA's are outstanding, let alone to help in preparing
> any of them; and there should be plenty of room to get decent benefits
> from improving the security system setup -- we went from being overloaded
> at one suite with six architectures and some 2600 packages pre-woody, to
> managing two suites, eleven architectures and 5200 packages today.
Outstanding DSA's are not the matter at hand; the bugs being discussed have
been public for a long time, hence the fuss about testing.
You suggest distributing the workload, and your concrete suggestions are
exactly the opposite of that. You want this to be the security team's
responsibility, while I'm saying to let maintainers (and anyone else) handle
it.
> > No, it is not at all the same as stable. The problem that is being
> > discussed in this thread is the presence of known, publicized security
> > holes in testing.
>
> Mmm. And are you really wondering why nothing's being done about it when
> the Debian Security Team passively obstruct it every time it's brought up?
"Passively obstruct"? Is that what it is when someone declines to take on
additional work that is arbitrarily assigned to them?
> > > In any event, testing-proposed-updates exists and works at
> > > present, the only thing missing is people reliably uploading to it, and
> > > evaluating whether uploads work well enough to be included in testing
> > > or not. All the technical issues have already been addressed.
> > In that case, I invite any maintainer with a security fix for their package
> > in 'testing' to upload it to testing for testing-proposed-updates. Problem
> > solved.
>
> Why not invite them to upload to `testing-security' on
> security.debian.org, exactly? You know, so that we can get security
> updates for testing on the day they're made public, rather than a few
> days afterwards once the maintainer works out what's going on?
You know, because testing-security must be processed by the security team,
and that just gets in the way of maintainers who want to fix bugs. Why
don't they upload them to testing-proposed-updates instead? You have said
that it works and all known technical issues have been addressed. Just give
maintainers the power they want.
> In any case, it doesn't solve the problem: security bugs get found while
> maintainers are on vacation, maintainers can choose not to care about
> testing and not bother, and maintainers can be simply unaware of problems.
> Are you sure you didn't really mean "Buck passed." ?
This is what NMUs are for. Maintainers who don't care about the quality of
the next Debian release are poor maintainers. The samba maintainers clearly
do care, and already have packages prepared. They want to get them into
testing. Why don't you want them to upload them to
testing-proposed-updates?
> > Are you the one who will be responsible for reviewing the packages?
>
> It's easily delegated to anyone with the time and ability ("touch; chmod;
> chown"). Personally, I don't think I'd do a good job of it.
It's obviosly not a question of technical ability; it's one of
responsibility (again). Someone needs to volunteer to own it.
> > release
> > <programming> (Or "released version", "baseline") A version of
> > a piece of software which has been made public (as opposed to
> > a version that is in development, or otherwise unreleased).
>
> So, you're contending that "testing" hasn't been made public? Or you're
> contending that people regularly upload development versions of packages
> to testing? Or are you contending that there's a line somewhere between
> annual updates and daily updates that makes security support unnecessary?
No, I'm contending that testing is in development. It's a daily snapshot.
It doesn't make any sense to release patches and security advisories for a
snapshot which will be overwritten in the near future. One fixes the
supported, stable release, and whatever will become the next snapshot.
--
- mdz
Reply to: