[tor-dev] [Proposal] A simple way to make Tor-Browser-Bundle more portable and secure

[Ximin Luo]

libc is dynamically linked so one distribution-level upgrade will fix one libc problem. As opposed to having to rebuild every single program and trying to ship that to users in a huge update. The former is less complex.

Statically linking shifts the burden of tracking and fixing security bugs, away from the maintainers of that library who know it best, onto the program that does the static linking. Big development teams like Google can handle this responsibility and expend the extra cost needed to make it work. Most other projects cannot. Also many people, such as yourself, don't even seem to be aware in this fundamental shift in responsibility and development costs. This is quite dangerous and naive.

Ivan Markin:
> Yawning Angel:
>> Having to rebuild the browser when the libc needs to be updated seems
>> terrible as well.
> 
> Why is it terrible?
> Using static linking drastically reduces overall *complexity*
> (~1/security). If you do use libc code in your stuff then it's a part of
> this stuff.  If there is a bug in libc - just rebuild your broken
> software. It either works or not. Doing dynamic linking is leaving it in
> superposition state.
> 
> I consider having the browser that builds for >30m is way more terrible.
> 
> From
> https://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/08/01_Static_linking/
> :
> 
>> I prefer static linking:
> 
>> Executing statically linked executables is much faster, because there
>> are no expensive shared object lookups during exec().
>>

Who cares?

>> Statically linked executables are portable, long lasting and fail
>> safe to ABI changes -- they will run on the same architecture even in
>> 10 years time. Never expect errors like
>> /lib/ssa/libstdc++.so.6:version 'GLIBCXX_3.4.4' not found again.
>>

When was the last time someone got this error? Like, 1992?

>> Statically linked executables use less disk space. Most executables
>> use only a small subset of the functions provided by a static library
>> -- so there is absolutely no reason to link complete static libraries
>> into a static executable (e.g. spoken for a hello_world.c you only
>> need to link vprintf statically into the executable, not the whole
>> static libc!). The contrary is true for dynamic libraries -- you
>> always use the whole library, regardless what functions you are
>> using.
>>
>> Statically linked executables consume less memory because their
>> binary size is smaller and they only map the functions they depend on
>> into memory (contrary to dynamic libs).
>>

Go and dynamically vs statically link libc to a "hello world" program right now and tell me what the size is.

>> The reason why dynamic linking has been invented was not to decrease
>> the general executable sizes or to save memory consumption, or to
>> speed up the exec() -- but to allow changing code during runtime --
>> and that's the real purpose of dynamic linking, we shouldn't forget
>> that.
> 

This guy is rewriting history. It sounds like he's talking about dlopen / dynamic loading, which is not the same thing as dynamic linking.

Please do some research before believing random shit on the internet.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git