6 ms·

I wish I had three hours to waste on why almost all of these points are either innacurate or willfully misleading. But I don't, so I'll just point out the singl

I wish I had three hours to waste on why almost all of these points are either innacurate or willfully misleading. But I don't, so I'll just point out the single biggest reason why static linking is harmful. Encryption libraries. If OpenSSL, or LibreSSL, or Go's encryption modules, or any gigantic encryption library has a vulnerability, you basically have to recompile, distribute, and then have your users download, every single god damn networking program. But it's worse than that. Because everyone wants to ship a statically compiled Go app, nobody packages for the distros. So now every user needs to go track down where they downloaded each of their static Go apps, safely download the update, verify its checksum or signature via a 3rd party, and upgrade the app. That is a logistical nightmare. Not only are apps going to remain vulnerable for way, way longer, more users will be compromised by phishing and other attacks because there's no package manager to safely automate all these updates (distros sign and verify packages for you). I've actually written a Shell quasi-package manager/installer just for statically compiled apps (cliv) so in theory that problem could be somewhat solved... But nobody even knows about that program, so the manual update problem still stands.

AshamedCaptain 5y ago
If you ever statically link OpenSSL, your binary now has a builtin expiration date. You are doing your users a disservice.
- marcosdumay 5y ago
  To be fair, if you dynamically link to OpenSSL, your binary has a builtin expiration date too, and it's very likely the same date.
  - nly 5y ago
    OpenSSL ABI has been fairly stable within a given series. Something compiled against 1.1.0a (Sep 2016) has a fair chance of running on a system that has 1.1.0l (Aug 2021). 5 years of binary compatibility is nothing to be sniffed at for a C library. https://abi-laboratory.pro/index.php?view=timeline&l=openssl https://abi-laboratory.pro/index.php?view=timeline&l=openssl
    - marcosdumay 5y ago
      Funny because I've seen incompatible changes twice on this timeframe. The last one I remember. It was moving the API that did version negotiation from recommended to deprecated and then removed status. But yeah, the API itself didn't change. All that changed is the recommended way to interact with the library, and the old one removed.
    - iggldiggl 5y ago
      The last release of IMAPSize e.g. dates from 2009 and can no longer connect to some IMAP servers that presumably don't support older SSL/TLS-versions, but by replacing the OpenSSL-DLLs with a recentish versions, everything works fine again.
  - AshamedCaptain 5y ago
    Not really. I have made updated versions of libSSL that allow use of new ciphers with the old ABI, for example. (Retro purposes). But for example this has been done to extend the life of other binary-mostly platforms (e.g. webOS). As long as I can change libSSL separately, this is trivial.
KronisLV 5y ago
> If OpenSSL, or LibreSSL, or Go's encryption modules, or any gigantic encryption library has a vulnerability, you basically have to recompile, distribute, and then have your users download, every single god damn networking program. Good, then you'd know that these 50 of your networking apps have each been tested by their developers' test suites and have no bugs that have been introduced as a part of this dependency. Essentially, there would be a server farm out there that'd run all of the tests so you wouldn't have to deal with prod breaking because of some new dependency version not taking every possible configuration into account. Of course, that implies: - that there are automated builds in place - that there are automated tests in place - that both of the above are run regularly, on every dependency update - that both of the above are actually meaningful (think close to 100% functionality coverage in tests) The current situation of relying upon dynamically linked code is only prevalent because we as an industry have decided not to even attempt to do the above. I'd say that it's a matter of not being willing to put in effort, not being willing to test our software and packages, and not being willing to develop software more slowly but thoroughly. Everyone wants "good enough" now, rather than "almost perfect" in 10 years, regardless of whether we're talking about developing software, or the tooling around it. > But it's worse than that. Because everyone wants to ship a statically compiled Go app, nobody packages for the distros. In my eyes, that just adds to the above - there are so many deployment targets out there, all of these different packaging systems that are used by different distros and all have numerous idiosyncrasies as opposed to a single good package manager, that people have been fed up with it and now just either ship Docker containers or expect you to download binaries.
chrisseaton 5y ago
If you just update an encryption library and ship only that… then who’s tested all the applications against the new version?
- salawat 5y ago
  Not the library author's problem. That's the consumer's problem. I'm not saying it's great, but it's how it works.
  - chrisseaton 5y ago
    > That's the consumer's problem. Well this is the explanation for why people are static linking! They don’t want to run someone else’s entirely untested code and bear all responsibility for any problems.
    - salawat 5y ago
      For the record? I'm totally fine with that. As I'm basically one of the static linking group, or "use dynamic libraries in a way non-distinguishable from static linking". If I'm relying on it, it's getting tested and I'm not going to dork with it without good reason once it is.
ghoward 5y ago
Author here. I think you are strawmaning my arguments. Personally, I would include encryption libraries in the "system libraries" (I used that term on purpose) that could be dynamically linked. However, even if they are, you still want to recompile every user whenever that library is updated because of possible ABI and API breaks. And some of those encryption libraries have a history of API breaks. Also, I am building the ideas I laid out in the post, which should make it easier to handle dynamically-linked and statically-linked encryption libraries.

AshamedCaptain 5y ago

If you ever statically link OpenSSL, your binary now has a builtin expiration date. You are doing your users a disservice.

marcosdumay 5y ago
To be fair, if you dynamically link to OpenSSL, your binary has a builtin expiration date too, and it's very likely the same date.
- nly 5y ago
  OpenSSL ABI has been fairly stable within a given series. Something compiled against 1.1.0a (Sep 2016) has a fair chance of running on a system that has 1.1.0l (Aug 2021). 5 years of binary compatibility is nothing to be sniffed at for a C library. https://abi-laboratory.pro/index.php?view=timeline&l=openssl https://abi-laboratory.pro/index.php?view=timeline&l=openssl
  - marcosdumay 5y ago
    Funny because I've seen incompatible changes twice on this timeframe. The last one I remember. It was moving the API that did version negotiation from recommended to deprecated and then removed status. But yeah, the API itself didn't change. All that changed is the recommended way to interact with the library, and the old one removed.
  - iggldiggl 5y ago
    The last release of IMAPSize e.g. dates from 2009 and can no longer connect to some IMAP servers that presumably don't support older SSL/TLS-versions, but by replacing the OpenSSL-DLLs with a recentish versions, everything works fine again.
- AshamedCaptain 5y ago
  Not really. I have made updated versions of libSSL that allow use of new ciphers with the old ABI, for example. (Retro purposes). But for example this has been done to extend the life of other binary-mostly platforms (e.g. webOS). As long as I can change libSSL separately, this is trivial.

KronisLV 5y ago

> If OpenSSL, or LibreSSL, or Go's encryption modules, or any gigantic encryption library has a vulnerability, you basically have to recompile, distribute, and then have your users download, every single god damn networking program. Good, then you'd know that these 50 of your networking apps have each been tested by their developers' test suites and have no bugs that have been introduced as a part of this dependency. Essentially, there would be a server farm out there that'd run all of the tests so you wouldn't have to deal with prod breaking because of some new dependency version not taking every possible configuration into account. Of course, that implies: - that there are automated builds in place - that there are automated tests in place - that both of the above are run regularly, on every dependency update - that both of the above are actually meaningful (think close to 100% functionality coverage in tests) The current situation of relying upon dynamically linked code is only prevalent because we as an industry have decided not to even attempt to do the above. I'd say that it's a matter of not being willing to put in effort, not being willing to test our software and packages, and not being willing to develop software more slowly but thoroughly. Everyone wants "good enough" now, rather than "almost perfect" in 10 years, regardless of whether we're talking about developing software, or the tooling around it. > But it's worse than that. Because everyone wants to ship a statically compiled Go app, nobody packages for the distros. In my eyes, that just adds to the above - there are so many deployment targets out there, all of these different packaging systems that are used by different distros and all have numerous idiosyncrasies as opposed to a single good package manager, that people have been fed up with it and now just either ship Docker containers or expect you to download binaries.

chrisseaton 5y ago

If you just update an encryption library and ship only that… then who’s tested all the applications against the new version?

salawat 5y ago
Not the library author's problem. That's the consumer's problem. I'm not saying it's great, but it's how it works.
- chrisseaton 5y ago
  > That's the consumer's problem. Well this is the explanation for why people are static linking! They don’t want to run someone else’s entirely untested code and bear all responsibility for any problems.
  - salawat 5y ago
    For the record? I'm totally fine with that. As I'm basically one of the static linking group, or "use dynamic libraries in a way non-distinguishable from static linking". If I'm relying on it, it's getting tested and I'm not going to dork with it without good reason once it is.

ghoward 5y ago

Author here. I think you are strawmaning my arguments. Personally, I would include encryption libraries in the "system libraries" (I used that term on purpose) that could be dynamically linked. However, even if they are, you still want to recompile every user whenever that library is updated because of possible ABI and API breaks. And some of those encryption libraries have a history of API breaks. Also, I am building the ideas I laid out in the post, which should make it easier to handle dynamically-linked and statically-linked encryption libraries.