[arch-general] glibc 2.18-5 question

[Thomas Bächler]

Am 27.09.2013 14:56, schrieb Chris Down:
> Well, static libraries are not a waste of space if it was intentional.
> Static linking should be preferred for a number of reasons[0], they
> should be preferred in any sane Linux distribution (of which,
> unfortunately I can't name any at the moment until stali comes out).
> 
> 0: http://sta.li/faq

Nothing about using static libraries is sane. That FAQ seems to be about
some bitterness about glibc and its code, which has nothing to do with
static and dynamic linking.

Now, to the key point:

> Aren’t statically linked executables less secure?
>
> 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.

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

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.

> We know that there is some overhead in re-compiling all affected
executables if a dependent library is insecure, but we don’t see this as
a critical disadvantage, because we also focus on a small and
maintainable userland, where only one tool for each task exists.

On a system like Arch that includes a several desktop environments, web
servers, web browsers, ... (tons of other stuff), that statement is
simply nonsense. In the 1970s, you would call the 'gzip' (or even
'decompress') binary to decompress a file, but in the year 2013, you use
a library API for that because it is more convenient, less error-prone
and more efficient.

The 'one tool for each task' has long become 'one implementation for
each task', but that implementation is no longer in a binary, but in a
shared/static library. If you really insist on the old way of doing
things, you will be unable to use any modern program because they don't
follow the old 'one tool' paradigm anymore, they don't call external
programs.

As an Arch user, you would first have to rewrite pacman to not use
libarchive, but to use xz, gzip and tar to handle packages and package
databases. After you've done that, you can start talking about
statically linking those tools - but at that point, pacman will already
be too slow to be usable in any way.


-------------- 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/e55035a4/attachment.asc>