Re: Stable security support
* Anthony Towns:
> 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].
There was at least one offer to do clerical work for the security team
by someone who shouldn't have much trouble to get a vendor-sec
clearance. Perhaps the problems extending the team stem from
different roots.
Actually, I'm not sure how important vendor-sec is for Debian at this
stage. The LWN numbers you quote indicate that Debian cannot compete
on timeliness with other vendor-sec subscribers. When we assume that
predisclosure is done through vendor-sec, and not through NISCC and
others who demand real NDAs, predisclosure access does not look
terribly relevant to Debian.
The testing security team data suggests that there are plenty of
unembargoed issues which lack updates:
<http://idssi.enyo.de/tracker/status/release/stable>
This list may seem huge, but so is the size of our distribution. But
until now, vulnerabilities which later proved to be relevant have been
addressed in a timely fashion. You might not beat others at
statistics, but I don't think we have failed our users.
That's why I think it's safe to ignore the embargoed issues for know,
and make sure we fix the unembargoed ones. In that sense, your
efforts to decouple them are appreciated.
> 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 another issue: the "single point of ownership" problem. If we
push out a funny package, all hell breaks loose. (Even if not done
maliciously, it's still a problem.) Some kind of review process is
needed, or some kind of staging area which can be used by more
adventurous users. The latter wouldn't deal with malicious changes,
but it could help to detect breakage before the update hits thousands
of machines (Microsoft calls this their "Patch Validation Program").
> 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.
It's also a real downer if you are close to fixing a pressing issue,
but cannot do so because you lack the necessary privileges.
> <Joey> It's not a pressing issue for the security team and there are
> more important items currently.
Does anybody know what they are, apart from bugs in certain packages
without upstream security support?
> * In order to avoid this, the project thus accepts that it is the
> responsibility of the project at large to resolve this issue.
I fully agree. Cursory reading of bugs-dist suggests that at least
some maintainers don't want to investigate issues affecting their
packages in stable. Maybe the past actions of the stable security
team have contributed to that approach (being non-responsive to
questions from DDs), but in my opinion, this profound lack of
enthusiasm on the package maintainers part might well be the root of
the problem.
Any GR on this topic should reinforce that the whole project is
responsible for providing security support, not just a single team.
(This is slightly different from what you propose; you restrict it to
responsibility for resultion of the current problems.) Once you upload
a package to unstable, either as a maintainer or sponsor, and have it
enter testing, you need to be prepared to support it in stable.
> - 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.
This seems to be a recurring problem. Delegation per GR is not quite
supported by the Constitution. I also feel the current lack of
leadership, but I doubt such GRs are the right approach.
Furthermore, Joey (Schulze) might strongly object the addition of more
paid team members (see his blog about the LinuxTag troubles).
Reply to: