On Wed, Mar 23, 2005 at 01:35:47AM -0800, Steve Langasek wrote: > Hi Joey, > > As I touched on briefly on IRC, there is an upcoming kernel security fix > that requires a bit of discussion. It appears that one of the security > fixes that was included in kernel-source-2.6.8 2.6.8-14 (and backed out, at > least temporarily, in 2.6.8-15), changes the kernel module ABI for a very > small portion of the network stack.
hi everyone, ... i guess i finished skulking (or sulking or however you say that in english), and let's get back to work. I wpologize for the negative treatment i gave some these past days. Now, i think there is an unsolvable problem with kernels and security and d-i build times and so on, which cannot be solved without some heavy work. The current situation is not sustainable for security kernel updates, and it is not acceptable to release d-i with known remote security holes, it will be the death of debain in any serious security-conscious usage if we do that. Now, the proposal is a little drastic, and means lot of work, work that i had planned to do for the etch kernels, but that contrary to the NEW handling and other issues i can and will do (provided you guys get to your senses too, and that i don't get three times in a row the same day outcry from three different guys from the d-i/release team, please speak which each other before you come bashing at people so we only get it once at least). The proposal is the following : 1) now that rc3 is out we forget about the current kernels, well, not exactly, but we forget about the current kernel build system, including .udebs. 2) we take as basis the ubuntu kernel build infrastructure. 3) we throw out the ubuntu patches, configs and 2.6.10 orig source tarball. 4) we add our (2.4.27/2.6.8) own patches, and the kernel configs for all our arches. 5) we add support for the series patch handling support which is superior to the ubuntu one. 6) we add support for per-arch/subarch patchsets, which is needed for replacing the current kernels. 7) we (well, probably joey and colin), adapt the .udeb generation to generate those .udebs directly from the kernel packages as ubuntu does. We need to keep our current working rc3 module list though. Once we have that, which can be done concurently with the remaining of sarge release process, we are in a good shape to launch a final rebuild of the d-i images with those kernels, and we will have an infrastructure which will allow streamlined new d-i uploads in a couple of says, even with kernel abi changes, since it would only need : A) fix the only kernel-source's security issue, check that it doesn't break arch/subarch specific patches (can be automated to a degree), and fix those. B) the security team launches the build on the security network, resulting in a set of security fixed .debs/.udebs. C) the security/d-i rebuilds d-i with those kernels. Should take less than a day, i believe, since we mostly already do daily builds of those. D) the iso images are autobuilt on a fast machine (i hear there is a new one available that does the job pretty fast), which may even if possible be only a partial rebuild because only a small subset of packages will need to be changed. Only A includes the real work, B-C can be automated, and the time delay on those can be quantified and get an upper bound. I believe this is a good solution, which i would have pushed for etch, but which i feel we do need for the sarge release, even if this means a little delay, altough this delay can be minimal indeed since the work can happen in parallel with the rest of the RC bug fixing, and we can easily check that the new kernels produce the exact same files built from the exact same sources/patches with the exact same configs, except for build host and timestamp modification they should even be md5sum equal, as was shown in the 2.4.27 powerpc kernel migration to a single package. Now, for this to be fully efficient, there is still a little change that needs done to d-i. Support for the kernel meta-packages for all arches. A common kernel-official or whatever package will be created, including all the kernel-latest or whatever fixes, and base-installer will exclusively install those packages (altough at lower priority it could propose to bypass them or something), since this is needed to make abi-breaking arches kernel security uploads transparent to the user doing an apt-get upgrade. Ok, this is my proposal, i am waiting for feedback, and i hope those that put me in your blacklist would reconsider and still follow up on this proposal. I am *NOT* interested in bashing though, so please get yourself lost before you start on that path. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
