Hacker News Reader

Comment by rvz | Hacker News Reader

> As Rust is designed for sensitive applications where reliability is important such as embedded or blockchain-like projects, it can raise concerns.

This is why I get very concerned with Rust projects using tons and tons of external crates. Especially cryptocurrency projects using Rust.

These sort of techniques can be used to compromise lots of them at once which in the very worst case can lead to loss of funds and is irreversible.

Unfortunately we will see the same issues found in NPM be found in crates.io with cargo.

Oh dear.

View on HN

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.

> 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?

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)

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.

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.

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

[2]: https://github.com/nothings/stb/blob/master/docs/stb_howto.t...

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.

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.

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

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

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

> What do you mean?

What I mean is that the situation you describe, with C libraries deployed in distro package managers, is a reality only on servers and extremely niche desktop platforms. Most of the world of software, even in the C programming language, does not work that way.

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").

Reply on news.ycombinator.com