Enrico Scholz wrote:
j.w.r.degoede@xxxxxx (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
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
