Re: [arch-general] glibc 2.18-5 question
On 2013-09-26 08:53, Gaetan Bisson wrote: Some Arch packages even provide static libraries for convenience, such as gcc and glibc. And unfortunately a few higher-level packages also provide static libraries because their maintainers did not notice the waste of space... 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 pgpmCt2ZyCzUW.pgp Description: PGP signature
Re: [arch-general] glibc 2.18-5 question
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] glibc 2.18-5 question
On 27/09/13 22:56, Chris Down wrote: On 2013-09-26 08:53, Gaetan Bisson wrote: Some Arch packages even provide static libraries for convenience, such as gcc and glibc. And unfortunately a few higher-level packages also provide static libraries because their maintainers did not notice the waste of space... 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 My favourite counter link calling that opinion full of shit: http://www.akkadia.org/drepper/no_static_linking.html
Re: [arch-general] glibc 2.18-5 question
On 27/09/13 01:15, LANGLOIS Olivier PIS -EXT wrote: Hi, I just checked what was the motivation for this 5th release and I have found: http://hmarco.org/bugs/CVE-2013-4788.html where it says: The vulnerability is caused due to the non initialization to a random value (it is always zero) of the pointer guard by the glibc only when generating static compiled executables. Dynamic executables are not affected. Pointer guard is used to mangle the content of sensible pointers (longjmp, signal handlers, etc.), if the pointer guard value is zero (non-initialized) then it is not effective. So, out of curiosity, how big is the threat since I am under the impression that almost 100% if not 100% of Arch binaries uses libc.so In short, I am not overly concerned about this. But fixing the issue was the right thing to do, so it will not spread any further. Allan
Re: [arch-general] glibc 2.18-5 question
On 2013-09-27 15:13, Thomas Bächler wrote: 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. 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). 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. 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. 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. IMO this is again a non-argument either way. 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, really, other than the fact it allows you to use a filename in which you can store the version number. But this is the purpose of a package manager, and documenting your build process. We could also argue that there is no standard way of storing version information in many languages, but that kind of misses the point, which is that the version is arbitrary, and should be metadata stored by the package manager. pgpKrgkKY2A_w.pgp Description: PGP signature
Re: [arch-general] glibc 2.18-5 question
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] glibc 2.18-5 question
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. pgpyST9W35NZX.pgp Description: PGP signature
[arch-general] glibc 2.18-5 question
Hi, I just checked what was the motivation for this 5th release and I have found: http://hmarco.org/bugs/CVE-2013-4788.html where it says: The vulnerability is caused due to the non initialization to a random value (it is always zero) of the pointer guard by the glibc only when generating static compiled executables. Dynamic executables are not affected. Pointer guard is used to mangle the content of sensible pointers (longjmp, signal handlers, etc.), if the pointer guard value is zero (non-initialized) then it is not effective. So, out of curiosity, how big is the threat since I am under the impression that almost 100% if not 100% of Arch binaries uses libc.so Greetings, Olivier CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
Re: [arch-general] glibc 2.18-5 question
[2013-09-26 15:15:12 +] LANGLOIS Olivier PIS -EXT: So, out of curiosity, how big is the threat since I am under the impression that almost 100% if not 100% of Arch binaries uses libc.so People are free to build static libraries on Arch and use them. There are probably not many who do that, but that does not mean we should not care for them. Some Arch packages even provide static libraries for convenience, such as gcc and glibc. And unfortunately a few higher-level packages also provide static libraries because their maintainers did not notice the waste of space... -- Gaetan
