On Fri, May 23, 2003 at 09:20:28PM +1000, Herbert Xu wrote: > So unless someone can come up with a solution to this problem, > we will have to live with multiple Debian source packages for now. > > This does make security fixes more difficult than it would be otherwise, > however, I do not think it is unsurmountable given enough cooperation > from the people involved.
I think that we can live with multiple source packages given a little bit of infrastructure which more closely follows the way that kernel development happens. We need to be able to introduce specific patches to all of our kernels while minimizing the possibility of errors. Errors include breaking kernel builds, breaking module packages, missing some kernel packages and patches, etc. We also need to consider users who need to build their own kernels. > Here is my rough idea as to how it can work: > > 1. The architectures should be treated as independent packages. By 'independent packages', do you mean that we should have separate kernel-source source packages for each architecture? This would seem to be a step backward. > We should not be shy of releasing DSAs for some architectures before > others. Since we cannot assume that all architectures are at the same > version, some will inevitably take longer to fix due to the back-porting > involved. This is already the case. However, look at the mess which results: s390 and mips have integrated one of the ptrace patches into their respective kernel-patch packages (DSA-276 and DSA-270). Now, how are we going to fix i386? If we integrate the patch into kernel-source-2.4.17 or kernel-source-2.4.19, then s390 and mips are now broken because they will conflict. > 2. We should be more liberal about adding new kernels to the stable > archive and getting rid of old ones. > > The main advantage to this is in fact security. It is routine for small > security fixes to enter a stable kernel unannounced. For instance, > between 2.4.18 and 2.4.19, dozens of unannounced small security which only > affect specific drivers were fixed. It also minimises any back-porting > that has to be done when a security alert is raised. I believe that we should not do anything to encourage this kind of irresponsible behaviour. If an upstream is not willing to share information about security fixes with us, we should not reward them by doing extra integration work to try to push a new upstream release into stable. What benefit is there in not announcing these problems? Security through obscurity? How can we inform our users of their exposure when we are not informed ourselves about security problems? > The disadvantage is of course the potential to break existing systems. > However, I believe this can be minimised through careful management and > thorough testing. It is also mitigated by the fact that we allow multiple > kernels to be installed simultaneously so it is easy to roll back. > > In fact, due to the use of modules, it is often impossible to make > security fixes which are module ABI compatible with previous kernels. For > example, the last two security holes (ptrace and net hash) both changed > the modules ABI. It is infortunate if this must sometimes happen, but hopefully it is an exception, and in those cases we will need to rebuild modules and provide for both kernel images to be installed at once. I don't see why the ptrace fix necessitated a change in the module ABI however, only that it was implemented that way upstream. > Let me make it a bit more concrete as to what we can do about woody > right now. Yes, on that note: could you send any separate patches that you have for these issues to [EMAIL PROTECTED] - CAN-2003-0001: etherleak - CAN-2003-0127: ptrace - CAN-2003-0244: ip route cache hash - CAN-2003-0246: ioperm issue - CAN-2002-1380: mmap() on /proc/pid/mem - CVE-2002-0429: lcall7 DoS > Problem: Too many kernel-source packages. > > This is caused in part by gratuitous kernel-patch dependencies. > Kernel-patch packages should *never* depend on a kernel-source > package since the user can always use a kernel tar ball. Here is a quick list for unstable: mizar:[...deb/notmine/security/kernel] apt-cache dumpavail | grep-dctrl -nsPackage -FDepends kernel-source- kernel-patch-2.2.20-powerpc kernel-patch-2.4.19-powerpc kernel-patch-2.4.20-hppa kernel-patch-2.4.20-ia64 kernel-patch-2.4.20-powerpc Shall I file bugs for these so that they can be fixed for sarge? > Solution: Remove offending kernel-patch packages and kernel-source > packages. Users of those kernel-source packages should be encouraged to > upgrade to a later version. I'd recommend that we keep 2.4.18 and inject > 2.4.19/2.4.20 as soon as possible. All architectures have kernel images > in either stable or proposed-updates that is at least 2.4.18 or higher. Removing kernel-patch package from stable does not help users who are running kernels built from them, and this is not the least of the problems, either. Linux 2.4 does not exactly have a clean record when it comes to compatibility. What happens when some other package in woody breaks as a result of blindly upgrading to a new kernel release? Do we then work to fix that package, and then retest that packages which depend on it still work? What if the package which breaks is, for example, glibc? It would not be the first time. Pushing a new kernel release is essentially punting to the user, forcing them to decide between old bugs and new bugs. -- - mdz
