19 ms·

This is an issue with any ecosystem. The alternative would be to have them in standard library which is silly. The actual solution I guess are domain specific

by natded 5y ago

This is an issue with any ecosystem. The alternative would be to have them in standard library which is silly. The actual solution I guess are domain specific languages.

rvz 5y ago
> This is an issue with any ecosystem. So repeating the same mistakes that NPM has into other package managers? We have therefore learned nothing at mitigating these supply chain issues then. > The actual solution I guess are domain specific languages. Any production real world examples of this?
oytis 5y ago
With any ecosystem that has a packet manager. Try inserting a dependency backdoor into a C++ project where dependencies have to be managed manually (and consequently are few)
- ziml77 5y ago
  Of course if they need to be manually updated, there's a strong likelihood that they are using vastly outdated versions of their dependencies. Users could be wide open to unpatched exploits.
  - oytis 5y ago
    Not necessarily. C/C++ relies vastly on dynamic linking which means keeping your dependencies up to date will be outsourced to distro maintainers. You'll have to make sure that your package builds for new versions of the distro.
    - notriddle 5y ago
      C relies vastly on dynamic linking. C++ cannot dynamically link templates, so it's pretty common for a C++ library to be made entirely of header files. Also, that's really only true of a small number of Linux and BSD flavors. Applications shipped on Windows, macOS, Android, iOS, or any of the Linux "application bundle" systems like the Steam runtime, Docker, FlatPak, will deliberately avoid using globally-specified dependencies. It's also commonplace to avoid declaring dependencies in C by vendoring them, like how VLC basically includes its own implementation of a bunch of data structures [1], and the entire universe of single-file libraries [2]. [1]: https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-deeper https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-... [2]: https://github.com/nothings/stb/blob/master/docs/stb_howto.txt https://github.com/nothings/stb/blob/master/docs/stb_howto.t...
      - ziml77 5y ago
        That first link is a good analysis of the situation when it comes to dependencies. It's really not straightforward unless you are targeting a specific OS distribution.
      - oytis 5y ago
        C++ ABI is PITA indeed, but exposing a C API for external linking is totally possible and is being actively used. Various cases of static linking (or header-only files) do indeed exist, but no sane C++ project (I'm not sure one can call ROS that without reservations) uses nearly as many static dependencies as typical Rust one does. > Also, that's really only true of a small number of Linux and BSD flavors. This is true on all major Linux distributions. > Applications shipped on Windows, macOS, Android, iOS If we are talking about security closed-source walled gardens are out of consideration right? > or any of the Linux "application bundle" systems like the Steam runtime, Docker, FlatPak This is sad indeed. Docker used right is just a distro inside a distro though, so anything that applies to distros applies here too.
        jcelerier 5y ago
        > If we are talking about security closed-source walled gardens are out of consideration right? yes, because there are no open-source apps on Windows and macOS of course...
        notriddle 5y ago
        > This is true on all major Linux distributions. Except Android, ChromeOS, and other Linux systems that get deployed as immutable images (stuff like Buildroot). Except servers, that’s almost all of the world’s Linux installs.
        oytis 5y ago
        > Except Android, ChromeOS Well, yes, these are proprietary walled gardens only using Linux as a kernel. > stuff like Buildroot Embedded Linux is special indeed. Core OE layers are well-maintained IMO, but as you use community ones the maintenance quality can vary. You have to take care of OTA of course which is a problem with no standardized solution so far, but the same applies if you develop in Rust for these platforms. But yeah, with embedded Linux you have to take responsibility for your whole system, so not much difference with Rust here (except at least if you have several apps having the same dependency you can be sure they'll use the same version of it). > Except servers, that’s almost all of the world’s Linux installs What do you mean? Most servers I've worked with would run one of the popular distributions, probably hardened and stripped of GUI stuff.
    - deleted 5y ago
      [deleted]
  - cozzyd 5y ago
    While vendoring is somewhat common (especially for C++ header-only libraries), often dependencies are provided by the OS package manager and dynamically linked (you have to recompile if the ABI changes, and hope that the API remains more or less stable, but that's usually part of the contract of a "major version").

by natded 5y ago

This is an issue with any ecosystem. The alternative would be to have them in standard library which is silly. The actual solution I guess are domain specific languages.

rvz 5y ago

> This is an issue with any ecosystem. So repeating the same mistakes that NPM has into other package managers? We have therefore learned nothing at mitigating these supply chain issues then. > The actual solution I guess are domain specific languages. Any production real world examples of this?

oytis 5y ago

With any ecosystem that has a packet manager. Try inserting a dependency backdoor into a C++ project where dependencies have to be managed manually (and consequently are few)

ziml77 5y ago
Of course if they need to be manually updated, there's a strong likelihood that they are using vastly outdated versions of their dependencies. Users could be wide open to unpatched exploits.
- oytis 5y ago
  Not necessarily. C/C++ relies vastly on dynamic linking which means keeping your dependencies up to date will be outsourced to distro maintainers. You'll have to make sure that your package builds for new versions of the distro.
  - notriddle 5y ago
    C relies vastly on dynamic linking. C++ cannot dynamically link templates, so it's pretty common for a C++ library to be made entirely of header files. Also, that's really only true of a small number of Linux and BSD flavors. Applications shipped on Windows, macOS, Android, iOS, or any of the Linux "application bundle" systems like the Steam runtime, Docker, FlatPak, will deliberately avoid using globally-specified dependencies. It's also commonplace to avoid declaring dependencies in C by vendoring them, like how VLC basically includes its own implementation of a bunch of data structures [1], and the entire universe of single-file libraries [2]. [1]: https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-deeper https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-... [2]: https://github.com/nothings/stb/blob/master/docs/stb_howto.txt https://github.com/nothings/stb/blob/master/docs/stb_howto.t...
    - ziml77 5y ago
      That first link is a good analysis of the situation when it comes to dependencies. It's really not straightforward unless you are targeting a specific OS distribution.
    - oytis 5y ago
      C++ ABI is PITA indeed, but exposing a C API for external linking is totally possible and is being actively used. Various cases of static linking (or header-only files) do indeed exist, but no sane C++ project (I'm not sure one can call ROS that without reservations) uses nearly as many static dependencies as typical Rust one does. > Also, that's really only true of a small number of Linux and BSD flavors. This is true on all major Linux distributions. > Applications shipped on Windows, macOS, Android, iOS If we are talking about security closed-source walled gardens are out of consideration right? > or any of the Linux "application bundle" systems like the Steam runtime, Docker, FlatPak This is sad indeed. Docker used right is just a distro inside a distro though, so anything that applies to distros applies here too.
      - jcelerier 5y ago
        > If we are talking about security closed-source walled gardens are out of consideration right? yes, because there are no open-source apps on Windows and macOS of course...
      - notriddle 5y ago
        > This is true on all major Linux distributions. Except Android, ChromeOS, and other Linux systems that get deployed as immutable images (stuff like Buildroot). Except servers, that’s almost all of the world’s Linux installs.
        oytis 5y ago
        > Except Android, ChromeOS Well, yes, these are proprietary walled gardens only using Linux as a kernel. > stuff like Buildroot Embedded Linux is special indeed. Core OE layers are well-maintained IMO, but as you use community ones the maintenance quality can vary. You have to take care of OTA of course which is a problem with no standardized solution so far, but the same applies if you develop in Rust for these platforms. But yeah, with embedded Linux you have to take responsibility for your whole system, so not much difference with Rust here (except at least if you have several apps having the same dependency you can be sure they'll use the same version of it). > Except servers, that’s almost all of the world’s Linux installs What do you mean? Most servers I've worked with would run one of the popular distributions, probably hardened and stripped of GUI stuff.
  - deleted 5y ago
    [deleted]
- cozzyd 5y ago
  While vendoring is somewhat common (especially for C++ header-only libraries), often dependencies are provided by the OS package manager and dynamically linked (you have to recompile if the ABI changes, and hope that the API remains more or less stable, but that's usually part of the contract of a "major version").