On Thu, May 15, 2003 at 10:06:47AM -0400, Matt Zimmerman wrote:
> On Thu, May 15, 2003 at 03:19:02PM +1000, Anthony Towns wrote:
> > On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman wrote:
> >> Do you honestly think would be a good idea to use testing-security this way
> >> on a continual basis?
> > Yes, I do. I think we should release DSA's for security problems in
> > testing, too.
> There's that "we" again. Why not unstable, too?
I'd have no problem with that.
> Round it out to a nice,
> even four distributions to simultaneously support, and 40 or so
> distribution*architectures. As if it doesn't take enough time already.
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.
> > The same applies to stable: the key differences are immediacy,
> > announcements and control, all of which are equally valuable for testing
> > as stable.
> 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?
> > 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
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?
> > 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?
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." ?
> 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.
> > > Sidestepping the process to provide this kind of "timely" security update
> > > for "unreleased" software, on the other hand, doesn't seem particularly
> > > valuable to me.
> > What, precisely, is unreleased about 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?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Dear Anthony Towns: [...] Congratulations --
you are now certified as a Red Hat Certified Engineer!''
Attachment:
pgpHB3vbVSkSp.pgp
Description: PGP signature