3 ms·

This is a package management problem, linking has nothing to do with it. Security updates, just like library updates, could simply trigger recreation and rebuil

This is a package management problem, linking has nothing to do with it. Security updates, just like library updates, could simply trigger recreation and rebuild of affected packages. Of course if certain package managers still do this kind of thing manually, it's on them. People shouldn't be manually bumping versions in package sources.

kbenson 8y ago
That's only a solution for people using package managers, and people using package managers for everything. People manually build stuff. People also manually install binaries than have their own dependencies (even installed wireshark for Windows? I know for a long time, libpcap was installed separately as a sub-process during install). For example, probably 99% of the people that build their own toolchain for development and pushing to production. People also install separate package management systems (brew, cygwin) that might not have their update mechanisms automatically run, or are infrequently run. This is a compilation and deployment strategy downside. You can mitigate (but not eliminate) this downside through a strong package management system that tracks all this (BTW, is there a package management system in current use that tracks statically compiled dependencies?), but only if users and administrators adhere to strict practices.
- zzzcpan 8y ago
  If you don't track updates in an automatic way, you are not going to even know whether you need to update something. So there is no point to talk about security updates without implying some reliance on a package management system. There are plenty of package management systems in current use where linking is an ideological or historical choice and has no relevance to security updates.
  - kbenson 8y ago
    > If you don't track updates in an automatic way, you are not going to even know whether you need to update something. With dynamic linking, you may get updates for programs that need them without knowing that it was needed. If you manually build Nginx with shared libraries, and later on some fix for PCRE comes down the line and you update libpcre, your Nginx install takes advantage of that the next time it restarts. This happens whether you manually updated PCRE or a package management system does it for you. This happens for things like Chrome and Firefox too, even though they ship with quite a bit statically compiled. There are still portions they expect the system to provide (if you've even tried to get chrome working on an older system, this becomes obvious). This is an advantage, it exists, and people make use of it all the time. You can try to argue down it's relevance, but without successfully doing so first, I think saying it's pointless is getting ahead of yourself. > There are plenty of package management systems in current use where linking is an ideological or historical choice and has no relevance to security updates. At the very least it would have relevance in that they would need to accurately track package dependencies and would not have the additional benefit of the package failing to install if they got it wrong. I've had plenty of times in the past where package management systems haven't even gotten that right, where everything installs but there's errors about missing libraries because of the way things are loaded on demand for some systems. There are benefits to not relying on some automated or manual tracking of this, where instead if you get it wrong it doesn't work. The fact that it requires a package management to mitigate this problem is itself a downside. To be clear, my argument is there are both upsides and downsides to dynamic linking, and that it's not purely all negative. By arguing against that you're positioning yourself as stating that it's not a trade off, so it's all bad (or all good, but that doesn't seem to be your point). Is that really the position you intend to stand on? It seems rather absolutist.
    - zzzcpan 8y ago
      There are benefits that arise from solving problems of broken infrastructure. I think of them as downsides, even though there is something to gain. And there are benefits that come from building good infrastructure. Those are upsides, as you don't take advantage of brokenness.
      - kbenson 8y ago
        Sure, but that's all mostly a matter of perspective and context. What works for you, and provides an upside, may be almost entirely a downside for other people in different circumstances. From the embedded developer, to the home user, to the workplace, to the deployment of hundreds of systems, to the cloud provider that provides the infrastructure for hundreds or thousands of those large deployments, and all the steps between, each has a slightly different set of requirements. At some levels, and package management system from someone else is superfluous or cumbersome (Google is going to do their own thing for their custom installs), and at others, space really matters (e.g. small embedded devices). UNIX based systems are used at all these levels, and thus it makes sense that there would be little consensus as to the best way to do this specific thing.
        zzzcpan 8y ago
        I get it, there is no good or bad, people have different models of the world and all. But still, there are certain infrastructural things objectively necessary for security updates to make any difference. Doesn't matter if it's embedded, desktop or massive server farms. Updates still require management. Like it doesn't matter if an IoT vendor publishes updated .so files if you have to download and apply them manually to each device. So even if you have to work with broken infrastructure, you still have to recognize that it's broken to find a workaround. And convincing people about upsides of static linking is not the hard part, there is consensus. The hard part is merely making static linking work and realizing for how much stuff it can't be done at all.

kbenson 8y ago

That's only a solution for people using package managers, and people using package managers for everything. People manually build stuff. People also manually install binaries than have their own dependencies (even installed wireshark for Windows? I know for a long time, libpcap was installed separately as a sub-process during install). For example, probably 99% of the people that build their own toolchain for development and pushing to production. People also install separate package management systems (brew, cygwin) that might not have their update mechanisms automatically run, or are infrequently run. This is a compilation and deployment strategy downside. You can mitigate (but not eliminate) this downside through a strong package management system that tracks all this (BTW, is there a package management system in current use that tracks statically compiled dependencies?), but only if users and administrators adhere to strict practices.

zzzcpan 8y ago
If you don't track updates in an automatic way, you are not going to even know whether you need to update something. So there is no point to talk about security updates without implying some reliance on a package management system. There are plenty of package management systems in current use where linking is an ideological or historical choice and has no relevance to security updates.
- kbenson 8y ago
  > If you don't track updates in an automatic way, you are not going to even know whether you need to update something. With dynamic linking, you may get updates for programs that need them without knowing that it was needed. If you manually build Nginx with shared libraries, and later on some fix for PCRE comes down the line and you update libpcre, your Nginx install takes advantage of that the next time it restarts. This happens whether you manually updated PCRE or a package management system does it for you. This happens for things like Chrome and Firefox too, even though they ship with quite a bit statically compiled. There are still portions they expect the system to provide (if you've even tried to get chrome working on an older system, this becomes obvious). This is an advantage, it exists, and people make use of it all the time. You can try to argue down it's relevance, but without successfully doing so first, I think saying it's pointless is getting ahead of yourself. > There are plenty of package management systems in current use where linking is an ideological or historical choice and has no relevance to security updates. At the very least it would have relevance in that they would need to accurately track package dependencies and would not have the additional benefit of the package failing to install if they got it wrong. I've had plenty of times in the past where package management systems haven't even gotten that right, where everything installs but there's errors about missing libraries because of the way things are loaded on demand for some systems. There are benefits to not relying on some automated or manual tracking of this, where instead if you get it wrong it doesn't work. The fact that it requires a package management to mitigate this problem is itself a downside. To be clear, my argument is there are both upsides and downsides to dynamic linking, and that it's not purely all negative. By arguing against that you're positioning yourself as stating that it's not a trade off, so it's all bad (or all good, but that doesn't seem to be your point). Is that really the position you intend to stand on? It seems rather absolutist.
  - zzzcpan 8y ago
    There are benefits that arise from solving problems of broken infrastructure. I think of them as downsides, even though there is something to gain. And there are benefits that come from building good infrastructure. Those are upsides, as you don't take advantage of brokenness.
    - kbenson 8y ago
      Sure, but that's all mostly a matter of perspective and context. What works for you, and provides an upside, may be almost entirely a downside for other people in different circumstances. From the embedded developer, to the home user, to the workplace, to the deployment of hundreds of systems, to the cloud provider that provides the infrastructure for hundreds or thousands of those large deployments, and all the steps between, each has a slightly different set of requirements. At some levels, and package management system from someone else is superfluous or cumbersome (Google is going to do their own thing for their custom installs), and at others, space really matters (e.g. small embedded devices). UNIX based systems are used at all these levels, and thus it makes sense that there would be little consensus as to the best way to do this specific thing.
      - zzzcpan 8y ago
        I get it, there is no good or bad, people have different models of the world and all. But still, there are certain infrastructural things objectively necessary for security updates to make any difference. Doesn't matter if it's embedded, desktop or massive server farms. Updates still require management. Like it doesn't matter if an IoT vendor publishes updated .so files if you have to download and apply them manually to each device. So even if you have to work with broken infrastructure, you still have to recognize that it's broken to find a workaround. And convincing people about upsides of static linking is not the hard part, there is consensus. The hard part is merely making static linking work and realizing for how much stuff it can't be done at all.