5 ms·

> Makes it easier for upstream and the distro. Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which u

> Makes it easier for upstream and the distro. Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Specifically for Rust, there's also the fact that most projects use a lock file and if your build process respects it, you now have to wait for the upstream to update it and release a new version (or update it yourself). And if your build process doesn't respect the lock file (or the project doesn't use it) and you just fetch the latest compatible dependencies at the time of build, you now have no idea if you're affected or not by the vulnerability because you don't have the exact resolved versions stored anywhere (https://github.com/rust-lang/rfcs/pull/2801 https://github.com/rust-lang/rfcs/pull/2801).

palata 2y ago
I totally agree. Static linking is essentially easier for people who don't want to care. But ignoring security does not mean it solves it, on the contrary. Static linking comes with a lot of issues, just like dynamic linking is not perfect. I really think it depends on the use-case, and that's why I want to have the choice.
josephg 2y ago
> Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Packages get rebuilt all the time. This is fine. As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do.
- palata 2y ago
  > It would make this sort of vulnerability scanning much easier to do. Scanning, sure. Fixing... surely much harder than with shared libraries.
  - josephg 2y ago
    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.
- LtWorf 2y ago
  > Packages get rebuilt all the time. This is fine. You forgot to link the image with the dog sitting in the fire.
- dolmen 2y ago
  > As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do. Go binaries have that. You can apply "go version -m" to any recent Go binary. Also "govulncheck". Examples: go version -m $(which go) go install golang.org/x/vuln/cmd/govulncheck@latest go version -m $(which govulncheck) govulncheck -mode=binary $(which govulncheck) for b in $(go env GOPATH)/bin/*; do govulncheck -mode=binary "$b"; done

palata 2y ago

I totally agree. Static linking is essentially easier for people who don't want to care. But ignoring security does not mean it solves it, on the contrary. Static linking comes with a lot of issues, just like dynamic linking is not perfect. I really think it depends on the use-case, and that's why I want to have the choice.

josephg 2y ago

> Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Packages get rebuilt all the time. This is fine. As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do.

palata 2y ago
> It would make this sort of vulnerability scanning much easier to do. Scanning, sure. Fixing... surely much harder than with shared libraries.
- josephg 2y ago
  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.
LtWorf 2y ago
> Packages get rebuilt all the time. This is fine. You forgot to link the image with the dog sitting in the fire.
dolmen 2y ago
> As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do. Go binaries have that. You can apply "go version -m" to any recent Go binary. Also "govulncheck". Examples: go version -m $(which go) go install golang.org/x/vuln/cmd/govulncheck@latest go version -m $(which govulncheck) govulncheck -mode=binary $(which govulncheck) for b in $(go env GOPATH)/bin/*; do govulncheck -mode=binary "$b"; done