pertusus@xxxxxxx (Patrice Dumas) writes: >> an Bug #176579 I have a review, where soneone will published a >> package with programs which are staticly linked agains the >> dietlibc. >> >> Becouse I'm unsure about the packaging guidelines I want hear the >> mind of other contributors on the list. > > It seems to be aginst the packaging guidelines. I do not see a violation there. Packaging guidelines are stating | Also applications linking against libraries should as far as possible | link against shared libraries not static versions. There is a "should" but not a "must" so it is possible for a packager to link statically when there are good reasons. Because in this case you have only disadvantages when linking against glibc without having a single gain, the choice is easy: link against dietlibc. > However it is a very specific case where static linking is advocated for > speed reasons. If I am not wrong, the reasons to link dynamically because > of the implementation of some glibc functions doesn't hold. However the > security issue is still there. Which security issues? Tools in 'ipvsd' are doing only some syscalls resp. the (perhaps) exploitable code sits in ipvsd and not in dynamical linkable libraries. The 'ipvsd' code itself is so small that it can be audited completely and you can protect against attacks by reviewing the code instead of trusting into things like non-exec stack and randomized heap which help against some, but not all attacks. > So, in that precise case, the choice is between security and efficiency. 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. Enrico -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
