On Wed, May 14, 2003 at 10:07:16AM +0300, Chris Leishman wrote: > I can't just start doing it. For one this is the sort of issue that > needs a bit of consensus and input from the people actually in charge > of the process. It's not like just submitting a patch or uploading a > new package. I also clearly stated it's just an example of what could > be done, but I think there may be better ways...
> Another example might be to just replace the package with another > version that has a very, very loud debconf warning that it has known > security problems and asking if the user really wants to install it. But, this example suffers from the exact same problem as trying to get a fixed package into testing. For an individual security problem, preparing a non-vulnerable source package is fairly easy; in the case of Samba, it's a no-brainer, since all that's needed is to take the last stable security update, review it, and stamp it with a new version number. Getting it built for 11 binary architectures, however, is more difficult if we're not able to use either t-p-u or the security buildd infrastructure to accomplish this (anybody else remember that woody's release was delayed because the security team was unwilling to do binary package builds by hand?), which would be the case if neither the RM nor the Security Team are willing to accept such package uploads. And if the packages will not be distributed from either ftp.d.o or security.d.o, the *most* difficult task is getting these packages into the hands of the users affected by the security exploits. After all, the users most likely to be affected are the ones who are *not* following Debian development, and have not paid attention to (or have not seen) the warnings that testing should not be used on a machine where you care about security. So how do you reach these people if you don't have the cooperation of those who control all of the debian.org download sites that these users are looking to exclusively? I personally feel that anyone running testing has a duty to subscribe to the debian-devel-announce mailing list, but in practice I know I've larted users for filing bugs about issues that were covered on d-d-a, so I don't have much confidence in the success of using an announcement list to get the word out. Those who have suggested that someone should step forward and just "start working" on a security repository for testing are either downplaying the significance of these issues, or have chosen to ignore them. Indeed, I gather there's at least some sentiment that those running testing who haven't made a point to get themselves into the loop on development and security issues get exactly what they deserve. I won't argue that, but I do argue that *we* don't get what we deserve when it becomes known that a large number of people running Debian have been rooted -- even if it's their own ignorance that's to blame. It makes us look bad, it makes upstream look bad, and it takes up the time of everyone involved. So where does that leave us? If none of the people who are in a position to approve packages for inclusion in testing or testing-security are willing to commit resources to doing so, it seems the only other option that could have an effect is to submit a patch to the website, to add a skull and crossbones everywhere that testing is mentioned. - Steve Langasek postmodern programmer
pgpIZKqZXQkwp.pgp
Description: PGP signature
