lkml.org 
[lkml]   [1996]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: No Distribution is 2.0.0 Current
Alan Cox writes ("Re: No Distribution is 2.0.0 Current"):
...
> Urghhhh.. Dont compile any networking programs with Debian in that case
> unless you mend the includes. Almost every network program will pick up
> things like IP_OPTIONS and do security checks. If you don't get those
> options built in then if you run 2.0 and don't have "Drop Source Routes"
> enabled your machine is potentially vulnerable to basic attacks.
>
> In terms of other things you probably have the wrong definitions for all
> the core network structures. Since for some programs and libc that will
> include a wrong struct msghdr its probably not good
>
> I can see why they use different kernel headers for their libc build,
> unfortunately for the debian people many tools decide if they are with 2.0
> and software runs better with the right headers, while some stuff like gated
> is just going to plain break with that scheme.

Surely this is missing a fundamental point: we, the Debian project,
have to ship binaries that will work on everybody's system, so that
our users can use the kernels that they choose.

Furthermore, we have to do this while running all manner of kernels
ourselves.

If the kernel system call interface has changed in such a way that
binaries compiled against old kernel headers will do terrible things
when run on new kernels, or vice versa, then surely this is (a) a
problem with the kernel developers not thinking enough about backward
compatibility and (b) not something we can solve by using a particular
set of headers ?

Changes to kernel interfaces breaking the odd program so that they
need to be upgraded is OK, if something of a pain, but changes which
make the old programs work but insecurely (for example) are
pernicious, as are changes which mean that it's impossible to compile
a program so that it works on both old and new kernels.

All of this has little to do with whether we ship a particular set of
kernel headers with our libc package - in fact, if we were to upgrade
our libc to contain 2.0 headers then we would at least be able to
build binaries with 2.0 headers without necessarily requiring all of
our developers to upgrade to 2.0 simultaneously.

A Linux distribution is a very large piece of software engineering,
and comes is a point where expecting its maintainers to play
`catch-up' continuously with new and sometimes-incompatible kernel
interfaces is unreasonable.

Expecting the users to know to upgrade everything at once is
unreasonable too, IMO.

Ian.
(maintainer of dpkg)


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.113 / U:7.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site