On Wed, Aug 11, 2004 at 12:04:30AM -0400, Andres Salomon wrote: > On Tue, 10 Aug 2004 13:19:22 -0700, Steve Langasek wrote: > > The upgrade-only kernels would be intended solely as an intermediate step > > during the upgrade process; users should be encouraged to install kernels > > from the main archive as well as part of the upgrade process. As such, we > > can probably dispense with security support for the upgrade-i386 kernel > > packages if necessary. > If we force it to be intermediate, that's fine (ie, we force 2.4.24 or > something upon the user, and then force them to upgrade to the latest 2.4 > kernel during the rest of the sarge upgrade). However, merely encouraging > a user means we'll probably end up w/ a bunch of users who keep running > the intermediate kernels. I wouldn't feel comfortable installing a kernel > w/ known security holes on a user's machine; especially during a > woody->sarge upgrade, as there's a good chance the machine in question is > in a production environment. So the question is, can we force a kernel > upgrade from this intermediate kernel? One way to force the removal of the intermediate kernel is to make something else in sarge conflict with it, but I can't think of any good candidates. (Kernels are notoriously difficult in this respect.) Given that no 386 users are going to be adding the necessary line to their apt sources without having read the 386-specific upgrade information, and given that this kernel won't be vulnerable to any exploits that don't also affect our latest woody kernels (and anyone running a newer hand-built kernel doesn't need our transition kernels), I think it's sufficient if we use big red letters in the documentation when telling users that these kernels won't have security support. In practice, it probably makes sense to continue security support for that directory as long as the security team does for woody in general, however long they decide that to be. > Or even better, can we simply do something similar to what the udeb > folks do, and keep this intermediate kernel using the image and > modules from the latest proper 2.4 -386 package that's in sarge? IIRC, the problem with this approach was that newer kernel packages depend on newer tools than what's available in woody, which in turn run up against the C++ ABI change that prompted the whole need for the kernel emulation patch. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature