On Thu, May 15, 2003 at 10:28:48PM -0400, Matt Zimmerman wrote:
> 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.
I don't have a problem helping other people do the work either. I'm
also happy for them not to do the work; what I don't like is them then
complaining about it, or, worse, obstructing others from doing it.
> > 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;
Sure they are: if you're complaining that the security team already
has too much work to do, then it's outstanding DSAs that are exactly
the problem. If there aren't any outstanding DSAs, then it'd seem like
now would be the right time to see about doing a *better* job, rather
than just the same old one.
> the bugs being discussed have
> been public for a long time, hence the fuss about testing.
Yes. Duh. There have been various packages with security problems in
testing *ever since it's existed*. It's not news. Testing works that
way because it's simply not possible to get packages from unstable into
testing the same day they're uploaded, or anything approaching that.
The solution isn't to go into some bizarre reality denying mode and
pretend otherwise, it's to do *the exact same thing we already do for
stable*.
> 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.
You realise it's possible to add people to the security team, right? Or
to let them upload to the security archive without adding them to the
security team?
You also realise that anyone "handling" this is *by definition* part of
the security team, whether they're on the team@ alias or not?
> > > 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?
No, it's when someone refuses to accept even the possibility of the
work being worthwhile, publically claims it's not possible, and resists
anyone else who might want to help using the existing infrastructure
that's been set up.
> > 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.
So add some people to the security team.
> 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.
Yes, and funnily enough, uploads to -p-u have to be processed by the
release manager, either Joey for stable, or me for testing. How's the
phrase go? "You suggest distributing the workload, and your concrete
suggestions are exactly the opposite of that."
Again, the security architecture is there for a reason: it's so
we have a quick, effective way to get security updates out and
so we can prepare security updates before they've been publically
announced. testing-proposed-updates simply does not manage either of
those things, just as stable-proposed-updates doesn't.
Yes, it's possible to do security updates via t-p-u; it's absolutely no
easier to do it that way than via testing-security, and less effective.
> > 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.
Are you contending that the stable Debian release *isn't* in development?
I'm pretty sure that the OpenOffice.org guys are working on some stuff
to be included in the next stable release.
> It's a daily snapshot.
That's certainly true. Do you contend that it's impossible to have a
daily release schedule? How about hourly? Weekly? Monthly? Every two
months? Six?
> It doesn't make any sense to release patches and security advisories for a
> snapshot which will be overwritten in the near future.
"refuses to accept even the possibility of the work being worthwhile".
Security advisories, patches, and fixes are worthwhile whenever someone's
running software that has a security problem. It might not be possible,
or feasible, in all circumstances, but it's always worthwhile.
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:
pgpLVAcAXxSqk.pgp
Description: PGP signature