* 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). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
