Review Rules and staticly linked packages agains dietlibc

[Enrico Scholz]

pertusus at free.fr (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