Hey all,
As people following planet will already know, I've been working updating
dak (aka katie, the Debian archive kit, and dinstall) to support splitting
the queue of not-yet-released security updates into "unembargoed"
and "embargoed" sections, primarily so that folks from the testing
security group can do their work on the official security.debian.org
infrastructure, without stepping on vendor-sec toes [0]. My blog posts
on the topic are at:
http://azure.humbug.org.au/~aj/blog/debian/archive/unembargo
I think that's done now, to the point where, given some minor fixes
(noted in the most recent post above), the testing security guys can
support testing updates on security.d.o without interfering with the
stable security team.
The other aspect of the work is that it should enable the stable security
team to include members who aren't on the vendor-sec privilege list,
and thus share the load a bit more.
There's already been some public concern about the way stable security's
handled, such as:
http://wiki.debian.org/DPLTeamCurrentIssues
http://lists.debian.org/debian-project/2005/09/msg00235.html
-- "Security Team interaction, transparence, scaleability,
infrastructure and communication"
http://lists.debian.org/debian-devel-announce/2005/09/msg00017.html
-- "The recent security advisories showed some fundamental problems with
the security support for mozilla. ..."
http://necrotic.deadbeast.net/~branden/blog/exuberance/Debian/dpl_security_snapshot_2005.10.12.html
-- DPL report on Oldenburg security meeting
http://lwn.net/Articles/149976/
-- Debian compares poorly to other distributions
http://azure.humbug.org.au/~aj/blog/2005/09/09
-- my summary of the above, includes links to prior news articles
http://lwn.net/Articles/164180/
-- LWN: "it is worth noting that this is the first Debian kernel
update since sarge was released last June."
http://squishy.cc/blog/?p=59
http://squishy.cc/blog/?p=85
http://squishy.cc/blog/?p=86
http://squishy.cc/blog/?p=87
-- Andres Salomon (dilinger)'s blog posts about kernel security issues
Further, my understanding is that some of the recent "delegate" activity,
such as:
http://lists.debian.org/debian-devel-announce/2005/11/msg00009.html
http://necrotic.deadbeast.net/~branden/blog/exuberance/Debian/how_delegation_works.html
and
http://lists.debian.org/debian-project/2005/11/msg00132.html
http://wiki.debian.org/TaskDescription
have the security team issues as a major underlying motivation.
Having been poking at security support for about a month now, I can
make a couple of further notes to the above. One is that Joey's been
going it alone more than people have realised -- beyond simple things
like the majority of the team members (3 of the 5 full members) being
delisted at Oldenburg because they've been inactive for ages, there are
also things like ftpmaster not being aware of breakage in the uploading
functionality for at least a month, and the kernel team not getting back
to Joey about security updates for two months. The security secretaries
don't have permissions to do terribly much work, and as a consequence
aren't terribly familiar with the tools involved either -- thus limiting
the support they can provide too.
There are two comments from private conversations with the two current
security team members (Joey and mstone) that I think are worth repeating.
The first is in the context of talking to Joey about the overall changes
to the security infrastructure I was implementing:
<Joey> No, I would like to gather input from the others as well.
<aj> hrm, i've already talked to some others, who were you thinking of?
<Joey> mstone, noahm, skx
<aj> hrm, they got the original mail; i don't want to keep delaying this -
it's already been a week since that mail, and a month since i've been
working on this
<Joey> I'd rather delay the implementation and make it real.
<aj> i wouldn't, and at some point i'm going to have to say "it's ftpmaster's
job to maintain the dak-sec infrastructure"
<Joey> It's not a pressing issue for the security team and there are
more important items currently.
<aj> it's a pressing issue for the rest of the project
The second is from mstone, in the context of having people use the unembargoed
infrastructure to work on updates to stable, and assist the security team in
that way.
On Thu, Dec 15, 2005 at 01:21:37PM +1000, Anthony Towns wrote:
>TBH, I think adding people immediately is the better strategy
Well, I disagree. Our fundamental problem has been figuring out what
needs doing and tracking who's doing what. We're trying to address that,
and until we do adding people doesn't really help; we just can't scale.
Both quotes pretty much go to the same point: that the security team's
got enough on its plate at the moment, that trying to add people as well
is just too much work. And that's a hard point to argue with: stable
security support is very important, and even if we're already doing
a bad job, doing *worse* and screwing over our users as a consequence
isn't really acceptable, even if there are long term benefits.
But if that's not acceptable, and leaving things as they are isn't
good either, then what's the alternative? The only reasonable one I
can see is for the rest of the project to stop bitching and take on
the responsibility of restructuring our security support into something
that works well, without taking time or support away from Joey in the
meantime. I'm therefore thinking it's worth considering a GR that
the project resolve something like the following:
--
* The project expects the highest possible level of security
support for it users, and in particular that if we don't provide
better support than every other comparable distribution at all
times, we are beneath our own expectations.
* As such, security support for Debian 3.0 and 3.1 has been beneath
Debian's expectations.
* The existing security team is operating at capacity in providing
ongoing security support at present, and as a result, expecting
the security team to devote time and resources to resolving the
issue will cause Debian's security support to slip further beneath
expectations.
* In order to avoid this, the project thus accepts that it is the
responsibility of the project at large to resolve this issue.
* As such:
- the project authorises a team consisting of Joey Hess,
Steve Langasek and Micah Anderson to review the stable security
team's processes and resources and recommend any changes
they believe appropriate. With the Project Leader's approval,
these recommendations shall be put into effect.
- the project authorises the immediate addition of Martin Pitt
to the stable security team, with the expectation that he will
make every effort to ease the load on the existing members,
in so far as that is possible while ensuring his work does
not conflict or impede that of the existing members.
- the project authorises and expects all due assistance to be
provided to the review team and security team in carrying
out these activities, particularly by the Debian System
Administration team in ensuring access is available to
information on how the team is operating, and by the FTP Master
team in ensuring the capabilities of the security infrastructure
meet both existing and new expectations.
* The project offers the security team its thanks and congratulations
for their efforts to date, and expects the activities noted above
to be undertaken with the respect and courtesy due the individuals
who have singlehandedly provided Debian with security support over
recent years.
--
I'm not especially obsessed by the people I've named, and I've no real
idea if any of them would actually want to be involved.
FWIW, my reasoning was something like this: Joey Hess started the testing
security people and has written a recent blog article [1] that could be
taken as a comparison of the stable and testing security infrastructures;
Micah's a member of the testing security team and has been trying out
the unembargoed stuff I implemented on security.d.o recently, and also
contributed a fair bit to the security team TaskDescriptions wiki page
mentioned above; and I'd imagine either release manager would have a
vested interest in ensuring security support for etch doesn't become a
showstopper. I also tried picking people who probably weren't interested
in working on stable security updates themselves, and who hadn't gotten
obviously frustrated with the problems already.
Martin Pitt has, aiui, expressed an interest in joining the security team
in the past, already has access to vendor-sec via his Ubuntu work, and
has been feeding updates to the existing security team already. Testing
security team members, kernel security guys, or the existing secretaries
might make equally good or better people to add immediately too.
Anyway, those are my thoughts, and I'm speaking only for myself. I think
it's worth considering the possibility of the project taking a more
active approach to resolving these issues rather than just increasing
the pressure on the security team to resolve it themselves, and I think
the above approach is in keeping with the volunteer nature of Debian
and has a hope of working. YMMV.
Cheers,
aj
[0] vendor-sec is a fairly private list to contact vendors about security
issues so they can produce fixes for their uses before the
vulnerability is made public knowledge. It's got fairly strict
disclosure rules.
[1] http://kitenet.net/~joey/blog/entry/ending_the_tyranny_of_unix_permissions-2005-12-06-19-03.html
Attachment:
signature.asc
Description: Digital signature