Re: itp: static bins / resolving static debian issues
Justin Wells <jread@semiotek.com> writes:
> Perhaps a few binaries, such as e2fsck, restore, and fdisk, should
> be static. If you selectively pick just those that would really be
> important, and would never be used by ordinary users, there is very
> little cost and very real gain.
This has all been argued before many times. I was even on your side at the
time, but the bottom line is that there would be basically nothing to gain and
real risks.
You would have to have a fairly large set of basically arbitrary binaries
statically linked to be able to do anything useful. The ones you named would
be useless without a half-dozen or so more. If you wanted to do this you could
make separate packages that installed them in /sbin or something like that.
NetBSD for example ships all of /bin and /sbin static. Anything short of that
and you're better off just going to a boot disk.
There _are_ real costs however in the form of security holes in libraries.
Normally on a dynamically linked system you can upgrade a shared library to
one that fixes a security hole and know that every application is now fixed.
If there are random statically linked binaries lying around linked against old
versions of libraries you can still have problems.
Incidentally there have been a few inaccuracies posted earlier. Apache would
continue functioning fine since fork(2) doesn't trigger any dynamic linking,
only exec. And the argument about data integrity is off-base, that might be
your priority or it might not. There are plenty of front-line web servers that
don't need to worry about data integrity over uptime.
--
greg
Reply to: