3 ms·

I do not understand the hate towards statically linked binaries. It has its place for mission critical tools.

regecks 8y ago
I feel like it's pretty easy to understand the hate. For example, the recent x.509 verification DoS patched in <Go1.11.3 required me to recompile, tag and redeploy bunch of services. And then also push an RPM to thousands of customer servers, which costs me CDN money :(. I would have preferred for myself, and my customers to just upgrade openssl. I am still a big fan of static binaries though, they more than make up for their downsides.
viraptor 8y ago
Very specific tools, sure. If you have the time, people, and skills to keep your own list of baked-in dependencies and monitor it for issues - great. But for a random person downloading something from the internet, it's a dangerous thing to default to.
- devereaux 8y ago
  I agree. It is a double edge sword. It requires skill and proper analysis. I should have been more specific. I explained my reason below on https://news.ycombinator.com/item?id=18713442 https://news.ycombinator.com/item?id=18713442
  - ex_amazon_sde 8y ago
    Even FAANG companies rely on distributions and other companies to spot vulnerabilities, rebuild libraries, test and validate them. Even if the company rebuilds everything, there's a huge benefit in knowing that you are using a well tested release instead of a less popular one or an internal fork. Also: security teams hate big security patches.
nineteen999 8y ago
Where did I say I hated it? It just has different security characteristics, and I think static linking proponents are sometimes a bit hand-wavy about the implications of those. I suppose my gut feeling is that it's more prone to issues of human error - why should I have to recompile my application if the security hole was found in a library I've linked to? With dynamic linking, assuming you're publishing your software for an OS with a conscientious approach to security patches, ie. pretty much all the major ones, it's a solved problem. With static linking, if you forget to update your binary, well, it's your problem.
ex_amazon_sde 8y ago
Static linking is really bad for security and it's not used more often in mission critical applications.
- burfog 8y ago
  Dynamic linking is also really bad for security. There exist whole classes of bugs that require it. Library substitution is a big problem. If an attacker can get a library into a place where the executable looks for libraries, the attacker gains control. Merely having the capability to load a dynamic library is an issue. Generally, this means it is possible to load code into the process. Library ABI mismatches can be security bugs. There can exist two pieces of software that can be installed and used separately without trouble, but which have security bugs when both installed. This happens for example when the second piece of software to be installed brings along an updated library that isn't fully compatible (even bug-for-bug) with the one that the other software came with.

I feel like it's pretty easy to understand the hate. For example, the recent x.509 verification DoS patched in <Go1.11.3 required me to recompile, tag and redeploy bunch of services. And then also push an RPM to thousands of customer servers, which costs me CDN money :(. I would have preferred for myself, and my customers to just upgrade openssl. I am still a big fan of static binaries though, they more than make up for their downsides.

viraptor 8y ago

Very specific tools, sure. If you have the time, people, and skills to keep your own list of baked-in dependencies and monitor it for issues - great. But for a random person downloading something from the internet, it's a dangerous thing to default to.

devereaux 8y ago
I agree. It is a double edge sword. It requires skill and proper analysis. I should have been more specific. I explained my reason below on https://news.ycombinator.com/item?id=18713442 https://news.ycombinator.com/item?id=18713442
- ex_amazon_sde 8y ago
  Even FAANG companies rely on distributions and other companies to spot vulnerabilities, rebuild libraries, test and validate them. Even if the company rebuilds everything, there's a huge benefit in knowing that you are using a well tested release instead of a less popular one or an internal fork. Also: security teams hate big security patches.

nineteen999 8y ago

Where did I say I hated it? It just has different security characteristics, and I think static linking proponents are sometimes a bit hand-wavy about the implications of those. I suppose my gut feeling is that it's more prone to issues of human error - why should I have to recompile my application if the security hole was found in a library I've linked to? With dynamic linking, assuming you're publishing your software for an OS with a conscientious approach to security patches, ie. pretty much all the major ones, it's a solved problem. With static linking, if you forget to update your binary, well, it's your problem.

ex_amazon_sde 8y ago

Static linking is really bad for security and it's not used more often in mission critical applications.

burfog 8y ago
Dynamic linking is also really bad for security. There exist whole classes of bugs that require it. Library substitution is a big problem. If an attacker can get a library into a place where the executable looks for libraries, the attacker gains control. Merely having the capability to load a dynamic library is an issue. Generally, this means it is possible to load code into the process. Library ABI mismatches can be security bugs. There can exist two pieces of software that can be installed and used separately without trouble, but which have security bugs when both installed. This happens for example when the second piece of software to be installed brings along an updated library that isn't fully compatible (even bug-for-bug) with the one that the other software came with.