On Thu, 2006-02-23 at 21:00 +0100, Enrico Scholz wrote: > pertusus@xxxxxxx (Patrice Dumas) writes: > > >> No, the choice is between ??? (sorry, I do not have an idea which > >> positive property would be brought in by 'glibc' linking) against > >> efficiency and building 'ipvsvd' with the tools it was designed for. > > > > You cannot rule out security issues in the library easily as long as > > the library is used, and ipvsd is a networking app, so security > > matters. > > 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. So, if ipvsd should suffer from problems it will be much more but ipvsd package to be in trouble. > (which is much > more complicated to audit than dietlibc). ... which adds additional code to monitor. IMO, dietlibc should be banned from Fedora. Its only purpose is to circumvent the OS's libc for highly questionable reasons. As a compromise, I could be persuaded to agree to dynamical linkage against dietlibc, but statical linkage against dietlibc is non-acceptable to me. Ralf -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
