* Martin Schulze: > it seems that less than two months after the release of sarge it is > not possible to support Mozilla, Thunderbird, Firefox (and probably > Galeon) packages anymore. (in terms of fixing security related > problems)
This is very unfortunate and happened much sooner than expected. Since this problem is potentially much more general (for example, it seems that upstream's security support for PHP 4.3 has already ended), it's better to search for a generic approach instead of a Mozilla-specifc one. We have to address at least the following concerns: * Our users need timely security updates. If no update is available and vulnerabilities or even exploit code have been published, they should be warned. * When a coordinator prepares a disclosure, Debian should provide input on Debian's status. * Some packages have been abandoned by upstream and there is very basic security support only (e.g. BIND 8). * Some upstream authors do not provide specific security fixes (PHP, Mozilla, GNU libc). Sometimes, no backports for the version in stable are available, and the packages are too complex that we can prepare them in a reasonable timeframe. * Some fixes are very invasive (because they address design issues) and thus impossible to backport. * security.debian.org is a single point of ownership. If we push out a malicious security update, really interesting things might happen. * Predisclosure information is, by its definition, only available under a socially enforced NDA (or, increasingly, real NDA). * Debian's capacities are limited, and it's a volunteer-driven organization. (Maybe I missed some points.) For simplicity, I'm going to ignore the predisclosure NDA problem in the reminder of this message. Addressing vulnerabilities post-disclosure is already hard enough, and the two or three weeks of time we gain doesn't seem to be a decisive factor anyway. The idea I've been thinking about is a two-stage publication process for security updates. Under this process, any DD can upload packages to a new apt-gettable archive on security.debian.org. Binary uploads are not permitted, though. DDs should exercise reasonable care when preparing the uploads. New upstream versions are discouraged, but not ruled out completely. We expect that users who use this package source know that they are essentially beta testers. Maybe we should call this the Debian Patch Validation Program. The Debian security team reviews the pending security updates. For example, it could use exploit code it has obtained under NDA to check if the vulnerabities are indeed closed. These reviews also help to ensure that Debian does not distribute a malicious security patch to a broader audience after a developer key has been compromised. This is also the reason why binary uploads are not permitted. After some time has passed and no showstoppers have been discovered by the patch validators or the security team, the security team pushes the updates to the real security archive. In principle, something like the migration to testing could be implemented. Maybe it's desirable to push multiple updates at the same time, on some predictable patch day. Certainly it must be possible to push out emergency updates when exploits are in the wild, or other circumstances suggest an immedate update. Packages for which no security support is provided need to be flagged in some way. Maybe some of the existing scripts which relate installed packages to bug reports could be used for that. But this would imply that we must exercise more care when recording security bugs in the BTS. As a consequence, responsibility to provide a fixed package for a published vulnerability no longer rests with the security team alone, but with all DDs. In principle, this is already true today, but as far as I can tell, our current practice does not reflect this. I'm not sure if this plan can be implemented. As far as I know, any change to the buildd infrastructure is very hard to implement for organizational reasons. It's also questionable if we can get enough developer support. But in my mind, the crucial change in this new process is the Patch Validation part, which allows us to consider updates which are significantly more far-reaching than five-liners fixing simple buffer overflow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]