Re: Maintaining kernel source in sarge
Matt Zimmerman <mdz@debian.org> wrote:
>
> In general, this is not a problem. The exception is coordinated disclosure,
> where it is important that fixes be available for all architectures in order
> to minimize exposure. In those cases, it would be helpful to coordinate
> with all of the kernel package maintainers ahead of time.
Agreed.
> Of course, we cannot expect anyone to tell us things that they do not
> realize themselves. I thought you were referring to changes with known
> security impact.
Well I do know at least some of those problems. But it'll require someone
with a fulltime job to sit down and list them all. Since IMHO it doesn't
make sense to just provide a partial fix to what is a wide-spread problem,
especially when you're just taking fixes from a new version which has
been available for a long time, I must say that it is not worth it.
> We cannot justifiably be too liberal with new releases in the hope of
> getting unknown bugfixes, as we are as likely to receive unknown bugs.
It's not just bug fixes. There are also new drivers or updates to
existing drivers that are required to make the system work on new systems.
Of course this also brings the possibility of breaking existing systems
when old drivers are updated. But that is hopefully what testing will
eliminiate or at least minimise.
We must remember that most of our concerns in this area is shared by
the upstream.
> Are task_struct and mm_struct exposed to modules? It does not seem like
Yes.
>> Firstly I'm not suggesting the uploading new versions in direct response
>> to a security alert. I'm saying that we should be keeping up with new
>> versions so that we can be better prepared for subsequent security alerts.
>
> That is, you are saying that we should try to run the most recent kernels so
> that we can patch them more easily? I'm wary of introducing churn in stable
> for problems which we don't yet know about.
Unfortunately it is my opinion that we have no choice given our current
release schedules.
> One example which comes to mind immediately is the grossly incompatible
> TUN/TAP changes around kernel 2.4.5. The UML skas breakage from the ptrace
> fix is another, but I don't know if that was possible to avoid.
Well first 2.4.5 is fair game since any stable Linux release in single
digits should be treated as fluid.
The ptrace breakage is not the fault of the upstream since they did not
actually release a new version. In fact, the next release will contain
the fixed patch.
> We also have to deal with the fact that miscellaneous changes between kernel
> releases can and do break third-party patches (EVMS 1.2.x, device-mapper,
> freeswan, etc.) that we ship and our users depend on to run their systes.
> If the only fix we provide is an updated kernel, then users can no longer
> use the patches that we supply.
I agree that we should try to maintain compatibility. But it should not
override the need to include new stable kernel releases from upstream.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Reply to: