4 ms·

> 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. Thi

> 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.
        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.
        2y ago
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

> 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.
        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.
        2y ago

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