4 ms·

Dynamic linking ends up being a wash or a net negative for # of recompiles when you consider that developers of important dynamic libraries break binary compati

Dynamic linking ends up being a wash or a net negative for # of recompiles when you consider that developers of important dynamic libraries break binary compatibility all the time on non-security-related changes.

quotemstr 11y ago
> developers of important dynamic libraries like glibc break binary compatibility all the time on non-security-related changes. You couldn't have picked a worse example. glibc goes to great lengths to maintain backward compatibility. glibc is practically the reason ELF symbol versions exist. https://www.redhat.com/f/summitfiles/presentation/June2/Developer%20Tools/Drepper_Writing%20Shared%20Libraries.pdf https://www.redhat.com/f/summitfiles/presentation/June2/Deve...
- sdijf8sdhf 11y ago
  Guess I was wrong about glibc, so I removed that from the comment. I seem to remember fairly frequent full system updates, with it as the center, when I used Linux, but it might have been another library at fault.
- heavenlyhash 11y ago
  And yet in practice, the number of steam games on linux that I can't run because the developers compiled them against a newer version of libc than I have is in the dozens.
  - quotemstr 11y ago
    Compatibility works the other way around. You can run binaries compiled against an older libc on a newer glibc, but there's no reason to expect that binaries compiled against a newer libc should be able to run against older versions of libc. If you demand that, you demand software stasis.
    - sdijf8sdhf 11y ago
      It's a libc implementation for christ's sake. If ever a library should remain in stasis, it would be a libc implementation.
      - oldmanjay 11y ago
        There's a clue in your formulation that guides you to the right answer - no useful library should ever remain in stasis. Or as it's generally said, the only software that never changes is software no one uses.
        sdijf8sdhf 11y ago
        That's just, like, your opinion, man; tell it to the retrocomputing folks. IMHO, the reluctance to "finish" a project and the stigma against something being "in maintenance mode" is responsible for most of the bloat and messes in modern software. Perhaps it's related to "CADT": http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html It's also, ironically, the cause of numerous security flaws. Maybe we wouldn't have to worry so much about security flaws in our libraries if we weren't constantly tearing them down and remaking them. Regardless, in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward. The POSIX standard is set in stone, the interfaces are stable, the data types are opaque, etc. Of course you can create new implementations of memcpy etc that take advantage of new instruction sets, but I don't see why you need to break binary compatibility to do so.
        jjnoakes 11y ago
        > in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward Well, since you can't think of one, there must not be one.
- stass 11y ago
  Symbol versioning came from Solaris, originally, and the actual de-facto standard was specified by Sun.
0x0 11y ago
Even if you were right about the bc breaks, I think it's still better to apply a security patch to a stable version of glibc and just deploy that, instead of ensuring every ELF file on the system is updated.
- quotemstr 11y ago
  > ensuring every ELF file on the system is updated. You're right. Keep in mind, though, that we're living in a world where people ship applications built with dependencies like this: deps = http://some.random.server.ru/some-library:1.4.4 and installation software like this: curl http://lol.hackme.cn | sudo bash Do you expect people to really understand the nuances of security updates?
  - 0x0 11y ago
    I do expect them to understand that, when they are arguing against it. :)
- sdijf8sdhf 11y ago
  I agree, and I think this approach works very well on Windows, where Microsoft has a serious commitment to backwards compatibility at any cost. But in my experience, there wasn't anywhere near the same level of appreciation for binary compatibility in the Linux userland (though Torvalds clearly cares about this in the kernel).
davexunit 11y ago
Sure, leave it up to the developers of each application to stay on top of the security updates for each library they bundle. Fantastic idea.
- shanemhansen 11y ago
  I say you leave it up to the distribution (Red Hat, Ubuntu).
- sdijf8sdhf 11y ago
  Chill out. I didn't say dynamic linking was "good" or "bad," or that it isn't right to put security first, just that this isn't as great of a benefit as it appears to be if library devs aren't careful to preserve binary compatibility (which most, in my experience, aren't).

quotemstr 11y ago

> developers of important dynamic libraries like glibc break binary compatibility all the time on non-security-related changes. You couldn't have picked a worse example. glibc goes to great lengths to maintain backward compatibility. glibc is practically the reason ELF symbol versions exist. https://www.redhat.com/f/summitfiles/presentation/June2/Developer%20Tools/Drepper_Writing%20Shared%20Libraries.pdf https://www.redhat.com/f/summitfiles/presentation/June2/Deve...

sdijf8sdhf 11y ago
Guess I was wrong about glibc, so I removed that from the comment. I seem to remember fairly frequent full system updates, with it as the center, when I used Linux, but it might have been another library at fault.
heavenlyhash 11y ago
And yet in practice, the number of steam games on linux that I can't run because the developers compiled them against a newer version of libc than I have is in the dozens.
- quotemstr 11y ago
  Compatibility works the other way around. You can run binaries compiled against an older libc on a newer glibc, but there's no reason to expect that binaries compiled against a newer libc should be able to run against older versions of libc. If you demand that, you demand software stasis.
  - sdijf8sdhf 11y ago
    It's a libc implementation for christ's sake. If ever a library should remain in stasis, it would be a libc implementation.
    - oldmanjay 11y ago
      There's a clue in your formulation that guides you to the right answer - no useful library should ever remain in stasis. Or as it's generally said, the only software that never changes is software no one uses.
      - sdijf8sdhf 11y ago
        That's just, like, your opinion, man; tell it to the retrocomputing folks. IMHO, the reluctance to "finish" a project and the stigma against something being "in maintenance mode" is responsible for most of the bloat and messes in modern software. Perhaps it's related to "CADT": http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html It's also, ironically, the cause of numerous security flaws. Maybe we wouldn't have to worry so much about security flaws in our libraries if we weren't constantly tearing them down and remaking them. Regardless, in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward. The POSIX standard is set in stone, the interfaces are stable, the data types are opaque, etc. Of course you can create new implementations of memcpy etc that take advantage of new instruction sets, but I don't see why you need to break binary compatibility to do so.
        jjnoakes 11y ago
        > in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward Well, since you can't think of one, there must not be one.
stass 11y ago
Symbol versioning came from Solaris, originally, and the actual de-facto standard was specified by Sun.

0x0 11y ago

Even if you were right about the bc breaks, I think it's still better to apply a security patch to a stable version of glibc and just deploy that, instead of ensuring every ELF file on the system is updated.

quotemstr 11y ago
> ensuring every ELF file on the system is updated. You're right. Keep in mind, though, that we're living in a world where people ship applications built with dependencies like this: deps = http://some.random.server.ru/some-library:1.4.4 and installation software like this: curl http://lol.hackme.cn | sudo bash Do you expect people to really understand the nuances of security updates?
- 0x0 11y ago
  I do expect them to understand that, when they are arguing against it. :)
sdijf8sdhf 11y ago
I agree, and I think this approach works very well on Windows, where Microsoft has a serious commitment to backwards compatibility at any cost. But in my experience, there wasn't anywhere near the same level of appreciation for binary compatibility in the Linux userland (though Torvalds clearly cares about this in the kernel).

davexunit 11y ago

Sure, leave it up to the developers of each application to stay on top of the security updates for each library they bundle. Fantastic idea.

shanemhansen 11y ago
I say you leave it up to the distribution (Red Hat, Ubuntu).
sdijf8sdhf 11y ago
Chill out. I didn't say dynamic linking was "good" or "bad," or that it isn't right to put security first, just that this isn't as great of a benefit as it appears to be if library devs aren't careful to preserve binary compatibility (which most, in my experience, aren't).