Re: On Mozilla-* updates
* 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.
Reply to: