[arch-general] glibc 2.18-5 question

Chris Down chris at chrisdown.name
Fri Sep 27 16:18:50 EDT 2013


On 2013-09-27 16:36, Thomas Bächler wrote:
> 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.

You've missed the point, which is about the currently tolerated size vs.
the actual size of linking with uclibc. It's not a direct comparison.

> > 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.

I don't see how that wasn't implicit, even in his version...

> >> 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.

There is a reason that there is package metadata.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20130927/2999784b/attachment-0001.asc>


More information about the arch-general mailing list