robert at linuxfromscratch.org
Mon Jan 10 23:29:48 PST 2005
On January 11, 2005 01:38 am, Archaic wrote:
> On Mon, Jan 10, 2005 at 10:43:50PM -0500, Robert Connolly wrote:
> > I know this might sound harsh, but I'm just saying it should be possible
> > to get away with zero static libs on a development box.
> > Comments?
> My only comment would be what do we actually gain from this in terms of
> security or stability?
It is possible for a dynamically linked program to put a static library inside
itself. tclsh will do this if you use --disable-shared. I don't think that
works with shared objects though because they're linked and loaded
differently. OpenSSL is a library that will have regular upgrades for
security vulnerabilities, and others too. If there are no static libs then
you can be sure upgrades will affect all the programs. This is more
LFS installs both so we have a more robust development environment, but for
et_dyn static is discouraged. Removing the static libs entirely is a mild
enforcement of an et_dyn object policy.
Aside from upgrading, I think this would be most helpful on boxes with users
who compile their own programs; with the hardened gcc specs and no static
libs everything they compile should be relocatable (pic) unless they
deliberately set -no-pie. Or for admins who don't pay close attention to how
their new packages are being linked.
I can't really think of things that are bad with this plan. Most of the static
libs will never get used, and of the ones that do get used its only a couple
times. I've been checking why insmod.static needs to be static, and loading
elf support is the only reason I can come up with, but since elf is native
for any modern system this isn't an issue; elf support should be built in.
More information about the hlfs-dev