a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
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
Reply to: