Review Rules and staticly linked packages agains dietlibc

[Ralf Corsepius]

On Fri, 2006-02-24 at 11:17 +0100, Enrico Scholz wrote:
> rc040203 at freenet.de (Ralf Corsepius) writes:
> 
> >> In another posting I gave a complete list of used *libc symbols. These
> >> were either simple syscall wrappers or well audited code (e.g. malloc())
> >> so you will the same (or better) security as with glibc
> > Which is part of the OS and is being used and monitored by the whole
> > linux community.
> 
> Do you have numbers, how many people read (and understood) the glibc and
> the dietlibc code?
It doesn't matter, it's widestly used, and therefore if an exploit or
bug should be exposed it'll be very soon be known in public.
Also, if behavioral change should be introduced into glibc, these will
be available for all applications which are dynamically linked to glibc.

All this doesn't apply to dietlibc.

> > IMO, dietlibc should be banned from Fedora. Its only purpose is to
> > circumvent the OS's libc for highly questionable reasons.
> 
> Efficiency is a "highy questionable reason"?
What you call efficiency, I call lack of understanding on software
engineering and software integration. 

A libc is an integral core part of the OS. It provides the essential
interface to an OS's kernel and resources, and therefore should not be
circumvented. Doing so (like dietlibc) is crappy design.

> > As a compromise, I could be persuaded to agree to dynamical linkage against
> > dietlibc, but statical linkage against dietlibc is non-acceptable to me.
> 
> Dynamical linkage in dietlibc is highly experimental, is not supported
> on all archs and you gain absolutely nothing in the current 'ipsvd'
> case.
You still don't seem to have understood: I say, there should not be any
room for dietlibc in any LINUX distribution - I'd consider to file a
request for removal, but unless dietlibc starts to infect my systems,
it's not worth the hassle of fighting.

Ralf