On Sat, Mar 22, 2003 at 02:01:19PM +0100, Martin Schulze wrote: > > current vulnerability track database in such a way that it could "drop" > > There's ongoing work for that. > Is there a timeframe on when this could be done? Do you guys need help to implement it? I don't want to code in something in the web pages that is going to be largely incompatible with what the security team is going to provide. I'm not sure which is the current status of the security's team database for tracking vulnerabilities but could it be possible to do the following: submit a mail when a new (high risk, the kinds of which deserves a CERT advisory or similar) vulnerability including information on affected packages and releases? I view the security vulnerability process as the following: 1.- a vulnerability is discovered 2.- (sometimes) the security team gets notified 3.- the vulnerability goes public [if Debian is vulnerable to it] 4.- the vulnerability is fixed 5.- new packages are built and uploaded to security.debian.org The way we do things now, people reading (only) debian-security-announce are only aware of a vulnerability affecting Debian on step 5 (when a DSA gets issued). Now, IMHO, it could be possible to notify people in step 3 maybe by issuing a DSW (Debian Security Warning) in order to raise awareness of the problem and to allow people to take appropiate (temporary) measures to fix the vulnerability. Notice that the time from 3 to 5 can be large depending on the ease of fix and the fact that packages have to be built for all architectures. The security team has the infraestructure (or so it seems) to send a pre-fabricated mail saying "We are aware that vulnerability X exists affecting Debian release Y (packages Z) and are working on it. You can take temporary precautions to avoid this by doing X until new packages that fix it are available". If this information is properly formatted we can do the same with DSWs as we currently do with DSAs, put them in the website and let them be parsed automatically to have (in security.debian.org) both information of things _fixed_ and things that are going to be fixed but to which our users are currently vulnerable. Again, this might need to be done only with high-risk vulnerabilities (say, remote code execution or local priviledge escalation) affecting basic (as 'standard') or popular (Apache? Samba?) packages. Now, I could commit to write these DSW but what's the point on doing it if the security team has already that information at hand? Regards Javi
Attachment:
pgpO4xWG0ocMt.pgp
Description: PGP signature