[arch-general] glibc 2.18-5 question

[Thomas Bächler]

Am 27.09.2013 16:10, schrieb Chris Down:
>> That FAQ seems to be about
>> some bitterness about glibc and its code, which has nothing to do with
>> static and dynamic linking.
> 
> Not really. The releated references to glibc are more about refuting the
> "size" argument when linking against it (as opposed to a more sane
> libc).

In his 'Aren’t statically linked executables huge?' section, he wants to
say that statically linked binaries are not as big as people think. For
that, he compares two binaries of ksh:

Static uclibc: 170KB
Dynamic glibc: 234KB

This comparison is entirely worthless. glibc is not optimized for size
and has lots of overhead (as he correctly states). Compile and link the
same code dynamically against uclibc and you will get something in the
tens of kilobytes.

I use OpenWRT on an embedded device, and they use uclibc and dynamically
linked libraries/binaries everywhere - the size difference to statically
linked binaries is incredibly huge here, to the point that using static
linking will result in a firmware image too large to even flash.

In fact, statically linked executables ARE huge and he is wrong.

He wants to criticise dynamic linking, but in fact only compares uclibc
to glibc.

>>> Several people argue (with implicitly requiring ABI-stability) that
>> dynamically linked executables benefit from security fixes in libraries
>> they depend on.
>>
>> What "some people argue" is true. If there is a vulnerability in zlib
>> (which actually happened a few years back), all that is needed is to
>> rebuild zlib and be happy. A statically linked system would need to find
>> every single binary that incorporates zlib and rebuild it.
> 
> IMO either way this is a non-argument (in both directions), because any
> sane distribution should be able to pinpoint what needs to be rebuilt.

In a dynamically linked situation, nothing (except the original library)
needs to be rebuilt. That is easy to pinpoint.

Now, if you only provide static libraries, your users will link
self-compiled tools against those. This happens automatically without
the user noticing. There is no tool in the world that can tell you which
binaries have been linked against library libfoo.a.

You cannot get away by saying that the distribution should be able to
pinpoint it. There are no records of such dependencies in the binaries.
If you write down which libraries have been used, you will forget one,
because common build systems have no way of recording that. You have to
write all of them down manually.

>>> This is true to some extend, but if there is a security flaw in a
>> dynamically linked library, all programs are affected as well; whereas
>> statically executables aren’t.
>>
>> This is the biggest pile of nonsense I ever read. If there is a flaw in
>> a library, all programs that use it are affected - including statically
>> linked executables that were built using that library.
> 
> That wording seems lost in translation (it was written by Anselm, who
> is not a native English speaker). I suspect it is supposed to read
> "statically linked executables aren't affected by vulnerabilities in the
> dynamic libraries installed on your system". I'll rewrite that.

Statically linked binaries are affected by the vulnerabilities in the
static libraries that were installed on your system _at build time_.

That is what needs to be said here and it is the single strongest
argument against static linking. The language barrier is no excuse for
not saying that.

>> It is even worse: There is no easy way to determine which version of the
>> library a specific binary was built against. This is a security nightmare.
> 
> Well, there isn't any more of a way to do that with dynamic linking,

There is no need to do it with dynamic linking: Any bugs (relevant to
security or not) are not in the binary, but only in the shared library.
Replacing the shared library with a fixed version solves the bug.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20130927/c44cdf2c/attachment.asc>