On Fri, 2006-02-24 at 11:17 +0100, Enrico Scholz wrote: > rc040203@xxxxxxxxxx (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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
