On Friday 20 February 2004 13.40, Simon Josefsson wrote: > Is it entirely impossible to have two security teams, or split the > current security team into two parts? One part that patches Debian > packages as soon as technically possible, and one part that follows > various CERT timing requirements? I can't see how CERT would > reasonable object to that model, as long as no information flow from > the CERT team to the non-CERT team, and it would allow the Debian > users to have access to fixes as soon as possible. I think this is the time where I'd like to see some hard data. Which DSA's would possibly have been released differently if such a reorganisation would have been in place? For those security problems, where information goes over CERT, nothing would be different. For those security problems, where information goes not over CERT (or some similar organisation who makes a release schedules), nothing would change. So there are those where information goes out to CERT, and some non-CERT entity either finds the flaw at the same time or receives info from CERT and decides not to follow their schedule. In some cases, that entity publishes the security information to the world - and I guess CERT will then be very quick to make its own announcement, as there's no point in waiting. Nothing would change again. In other cases, that entity will publish a fix with no or incomplete information. The SSH case, I guess. The situation would not change again, as Debian cannot publish a unknown fix until it is, eh, well, known. In other cases, that entity discloses informatin only to a select few parties, amongst them the non-CERT Debian security team. This is the one case where that scheme does make a difference. Has this ever happened in the past? cheers -- vbi -- Adding manpower to a late software project makes it later.
Attachment:
pgpE7GIv20SA2.pgp
Description: signature