5 ms·

Only because the build tooling is less mature. It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. For rust

Only because the build tooling is less mature. It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. For rust crates that are compiled and packaged straight from git, you could probably automate that today.

palata 2y ago
> It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. You still fundamentally need to rebuild (or at least relink) and re-distribute all the packages, whereas with shared libraries... well you just update that one package.
- kibwen 2y ago
  I hear the refrain "you'll have to rebuild your packages" a lot in these discussions, and I confess I don't see how this is a problem. Maybe it's a holdover from C and C++ veterans for whom figuring out how to build any given project is a Herculean effort, but for every other language with a first-class build system it's trivial.
  - amszmidt 2y ago
    Debian has about 59000 packages. Even rebuilding 1k of that is a significant pain on build infrastructure, specially in one go, if say a vulnerable library is found. You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated… Compare to upgrading a single shared library.
    - kibwen 2y ago
      The distro repositories are being continuously rebuilt, because packages are receiving continuous updates. In the meantime, as far as I'm concerned dynamic linking is itself a security failure, because if I run a binary I want to know exactly what code is being run, without having to worry about dynamic linking and loading nonsense inserting itself into my process.
      - comex 2y ago
        > The distro repositories are being continuously rebuilt, because packages are receiving continuous updates. At large timescales, yes. But not at timescales relevant for rapid security updates.
      - amszmidt 2y ago
        They aren’t being rebuilt with that kind of frequency as you might think. They get rebuilt when a change in the package is made, not when a change in a dependency is made — which is a huge difference. There are plenty of packages that might not get an update for a long time (month, half year, … whatever their release cadence might be). Dynamic linking makes it _easier_ to handle security, including checking if your program is linking to a broken library — static linking does not have the same means. Statically linked programs don’t mean you know what is being run either, you can always dlopen() and all kind of shenanigans like Go and Rust do. What is a security nightmare is statically linked binaries, you have no clue what they are linked against.
        kibwen 2y ago
        I'm against dlopen as well. If something makes use of LD_LIBRARY_PATH, rest assured that I want it excised from my system. Reproducibly-built, fully-static binaries are what I want, ideally with an accessible SBOM embedded.
        palata 2y ago
        So all your binaries are statically linked on your system? 100%?
        kibwen 2y ago
        That's the dream. I want a system that's 100% source-available, 100% reproducible, and 100% statically-defined. Nix looks like the closest thing to that right now.
        2y ago
    - eviks 2y ago
      Do you know whether someone has made an estimate based on the history of actual vulnerabilities of how much rebuilding would need to be done in a non-shared library approach?
      - amszmidt 2y ago
        Not to my knowledge. But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. If there is a bug in a shared library, one can replace it with a interm one very easily, and the whole operating system will use it. One can even replace it with a different implementation assuming ABI compatibility, without having to do "much". Enclaves like Go, Rust, Swift (things that insist on using direct sys calls, and eschewing system libraries) would need to implement their own versions, or use FFI, and then you're SOL anyway if you really insist to use static linking... And who knows what kind of bugs might crop up there that don't match whatever anything anyone else uses. Shrug :-)
        tracker1 2y ago
        For what it's worth, Rust uses libc by default in Linux. On the other side, there are quite a few self-updating applications out there (browsers), and source control systems like Github will push notifications, and even pull requests for out of date dependencies. So pushing out a new version of a given application is pretty easy. If the application comes through Flathub or self-updates then it doesn't have to wait for the distro maintainers to get the update out.
        amszmidt 2y ago
        That is a very, very tiny subset of things that are installed on any GNU or BSD system, and that need to get security fixes. Just recall the xz/sshd/system debacle, to patch your system all you needed was to replace libxz / libzma -- a DSO! This obviously ignores lots of other work -- but that work would have ballooned if standard practise was to statically link everything. The amount of work spent finding usages of static linkage, and figuring out which version of libxz (or whatever it was called) just to be very sure that one wasn't using the compromised version was atrocious, no thanks.
    - tracker1 2y ago
      Most USERS only run a handful of applications any given month. I think upgrading 1-2 applications is easier to reason with over even a hundred packages.
  - LtWorf 2y ago
    For distributions, it costs a lot of money they don't have to just be rebuilding stuff all the time. For randomly downloaded binaries from the internet it means you will most likely keep using it with the vulnerabilities for years to come.
  - palata 2y ago
    It really sounds like you see it from the point of view of a developer who has never thought about how a Linux distribution works. Yes, for you as a user it's simpler to link statically and not learn about anything else. But distros are a bit more elaborate than that.
    - josephg 2y ago
      It sounds like you see it from the point of view of a disto maintainer and never thought about how awful the experience is for software developers. I want to just depend on some specific, latest version of a library. I don’t want to have to go look at which version of that library exists in 18 different Linux distributions. I don’t want to deal with bug reports because Debian patched one of my dependencies or replaced the version I depend on with something newer or older. I’m happy for someone to update the version of my dependency if it has security patches. But the rest? A total nightmare. I’ll take cargo / npm / swift / etc style versioning every day.
      - palata 2y ago
        > I don’t want to have to go look at which version of that library exists in 18 different Linux distributions. If you make open source software, the solution is simply that you should not distribute your software [1]. Let distro maintainers do it, and suddenly it's a lot easier for you. If you make proprietary software, then it's not exactly the problem of the Linux distros anymore so sure, feel free to link statically. I personally think you should do a mix of both: libraries like openssl you want to link dynamically from the system. Now some obscure dependency you may have that breaks compatibility randomly and is generally not distributed by major distros, probably you want to link them statically. But you should know that you are then responsible for them and the security issues they may bring (i.e. you should monitor them and update them regularly). [1]: https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html https://drewdevault.com/2019/12/09/Developers-shouldnt-distr...

palata 2y ago

> It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. You still fundamentally need to rebuild (or at least relink) and re-distribute all the packages, whereas with shared libraries... well you just update that one package.

kibwen 2y ago
I hear the refrain "you'll have to rebuild your packages" a lot in these discussions, and I confess I don't see how this is a problem. Maybe it's a holdover from C and C++ veterans for whom figuring out how to build any given project is a Herculean effort, but for every other language with a first-class build system it's trivial.
- amszmidt 2y ago
  Debian has about 59000 packages. Even rebuilding 1k of that is a significant pain on build infrastructure, specially in one go, if say a vulnerable library is found. You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated… Compare to upgrading a single shared library.
  - kibwen 2y ago
    The distro repositories are being continuously rebuilt, because packages are receiving continuous updates. In the meantime, as far as I'm concerned dynamic linking is itself a security failure, because if I run a binary I want to know exactly what code is being run, without having to worry about dynamic linking and loading nonsense inserting itself into my process.
    - comex 2y ago
      > The distro repositories are being continuously rebuilt, because packages are receiving continuous updates. At large timescales, yes. But not at timescales relevant for rapid security updates.
    - amszmidt 2y ago
      They aren’t being rebuilt with that kind of frequency as you might think. They get rebuilt when a change in the package is made, not when a change in a dependency is made — which is a huge difference. There are plenty of packages that might not get an update for a long time (month, half year, … whatever their release cadence might be). Dynamic linking makes it _easier_ to handle security, including checking if your program is linking to a broken library — static linking does not have the same means. Statically linked programs don’t mean you know what is being run either, you can always dlopen() and all kind of shenanigans like Go and Rust do. What is a security nightmare is statically linked binaries, you have no clue what they are linked against.
      - kibwen 2y ago
        I'm against dlopen as well. If something makes use of LD_LIBRARY_PATH, rest assured that I want it excised from my system. Reproducibly-built, fully-static binaries are what I want, ideally with an accessible SBOM embedded.
        palata 2y ago
        So all your binaries are statically linked on your system? 100%?
        kibwen 2y ago
        That's the dream. I want a system that's 100% source-available, 100% reproducible, and 100% statically-defined. Nix looks like the closest thing to that right now.
        2y ago
  - eviks 2y ago
    Do you know whether someone has made an estimate based on the history of actual vulnerabilities of how much rebuilding would need to be done in a non-shared library approach?
    - amszmidt 2y ago
      Not to my knowledge. But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. If there is a bug in a shared library, one can replace it with a interm one very easily, and the whole operating system will use it. One can even replace it with a different implementation assuming ABI compatibility, without having to do "much". Enclaves like Go, Rust, Swift (things that insist on using direct sys calls, and eschewing system libraries) would need to implement their own versions, or use FFI, and then you're SOL anyway if you really insist to use static linking... And who knows what kind of bugs might crop up there that don't match whatever anything anyone else uses. Shrug :-)
      - tracker1 2y ago
        For what it's worth, Rust uses libc by default in Linux. On the other side, there are quite a few self-updating applications out there (browsers), and source control systems like Github will push notifications, and even pull requests for out of date dependencies. So pushing out a new version of a given application is pretty easy. If the application comes through Flathub or self-updates then it doesn't have to wait for the distro maintainers to get the update out.
        amszmidt 2y ago
        That is a very, very tiny subset of things that are installed on any GNU or BSD system, and that need to get security fixes. Just recall the xz/sshd/system debacle, to patch your system all you needed was to replace libxz / libzma -- a DSO! This obviously ignores lots of other work -- but that work would have ballooned if standard practise was to statically link everything. The amount of work spent finding usages of static linkage, and figuring out which version of libxz (or whatever it was called) just to be very sure that one wasn't using the compromised version was atrocious, no thanks.
  - tracker1 2y ago
    Most USERS only run a handful of applications any given month. I think upgrading 1-2 applications is easier to reason with over even a hundred packages.
- LtWorf 2y ago
  For distributions, it costs a lot of money they don't have to just be rebuilding stuff all the time. For randomly downloaded binaries from the internet it means you will most likely keep using it with the vulnerabilities for years to come.
- palata 2y ago
  It really sounds like you see it from the point of view of a developer who has never thought about how a Linux distribution works. Yes, for you as a user it's simpler to link statically and not learn about anything else. But distros are a bit more elaborate than that.
  - josephg 2y ago
    It sounds like you see it from the point of view of a disto maintainer and never thought about how awful the experience is for software developers. I want to just depend on some specific, latest version of a library. I don’t want to have to go look at which version of that library exists in 18 different Linux distributions. I don’t want to deal with bug reports because Debian patched one of my dependencies or replaced the version I depend on with something newer or older. I’m happy for someone to update the version of my dependency if it has security patches. But the rest? A total nightmare. I’ll take cargo / npm / swift / etc style versioning every day.
    - palata 2y ago
      > I don’t want to have to go look at which version of that library exists in 18 different Linux distributions. If you make open source software, the solution is simply that you should not distribute your software [1]. Let distro maintainers do it, and suddenly it's a lot easier for you. If you make proprietary software, then it's not exactly the problem of the Linux distros anymore so sure, feel free to link statically. I personally think you should do a mix of both: libraries like openssl you want to link dynamically from the system. Now some obscure dependency you may have that breaks compatibility randomly and is generally not distributed by major distros, probably you want to link them statically. But you should know that you are then responsible for them and the security issues they may bring (i.e. you should monitor them and update them regularly). [1]: https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html https://drewdevault.com/2019/12/09/Developers-shouldnt-distr...