Review Rules and staticly linked packages agains dietlibc

[Hans de Goede]

Enrico Scholz wrote:
> j.w.r.degoede at 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