[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Review Rules and staticly linked packages agains dietlibc



Enrico Scholz wrote:
j w r degoede hhs nl (Hans de Goede) writes:


Why? Because static linking is BAD for lots of reasons,

Please tell me, why static linking is BAD in *this* case.


I just did a quick grep for your email in owners.list and I'm amazed by the fact that someone who maintains as many security related packages as you needs to ask.

Even in glibc which is widely used and audited security holes turn up quite regular, so this will most probably happen for dietlibc atleast as often as for glibc. When this happens we don't want to have to track which packages all are staticly linked against it. With the SSL stuff in ipvsd chances for holes are even bigger, so I would not only like to argue that ipvsd should not staticly link against dietlibc, I would like to add that I believe that the ssl lib used by ipvsd belongs in a seperate package (it has a seperate upstream) and that this seperate package should only contain .so files.

many the same reasons why the packaging guidelines state that
packages should not compile and (staticly) link against their own
version fo system libs,

The "should" in the packaging guidelines was intentionally. It leaves
room to link statically when this is the better choice and in this case,
dietlibc is the better choice.


Not when this is a better choice, it doesn't say when this is a better choice anywhere, it says "Static libraries should only be included in exceptional circumstances." I guess I can come up with a zillion more small programs which will be smaller and faster with dietlibc, thats not what this is about, the should is there in case its impossible to avoid this without tons of work. Not for this silly it saves a few kB case.


that is exactly what you're doing now linking against an own version
of system libs.

??? I do not see where 'ipvsd' links against a "local copy of a library
that exists on the system".


Its staticly linked, this it gets its own private copy hardcoded into the binary. A copy which is functional and api compatible with the system c library, so yes this is linking against a "local copy of a library that exists on the system"


is the exception that confirms the rule. Also notice:
"Static libraries should only be included in exceptional circumstances."

'ipvsd' does not provide static libraries.


Nor should it use them, thats the whole point, we don't want to provide them because we don't want apps using them.


(modern PC's are _fast_ and have _lots_ of mem),

That's a really stupid argument...

No its not, as my paid fulltime job I write code for computers with 8 kB of "harddisk" and 512 bytes of ram I know when every byte matters and when it doesn't. If you really care about speed and foodprint join a project like: http://live.gnome.org/MemoryReduction That is where the real gain is to be had.

when there are ways to make things
work better, these ways should be gone. Again: linking against 'dietlibc'
has only advantages for 'ipvsd'.


When the tradeof is a small gain in speed and footprint versus maintainability and security then the disadvantages of your choice outway the advantages. So saying that there are only advantages is false as there are clear disadvantages.

But this entire discussion is mood anyways. We have clear guidelines and you are in clear (and unnescesarry) violation of the guidelines. If you don't like the guidelines propose to FESco to change them, don't just do as you want under an exception which is for "exceptional circumstances." which isclearly not the case here.

Regards,

Hans









[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]