July 2, 2024
Sylvain Kerkour writes:
Rust adoption is stagnating not because it's missing some feature pushed by programming language theory enthusiasts, but because of a lack of focus on solving the practical problems that developers are facing every day.
... no company outside of AWS is making SDKs for Rust ... it has no official HTTP library.
As a result of Rust's lack of official packages, even its core infrastructure components need to import hundreds of third-party crates.
...the offical libsignal (from the Signal messaging app) uses 500 third-party packages.
... what is really inside these packages. It has been found last month that among the 999 most popular packages on crates.io, the content of around 20% of these doesn't even match the content of their Git repository.
...how I would do it (there may be better ways):
A stdx (for std eXtended) under the rust-lang organization containing the most-needed packages. ... to make it secure: all packages in stdx can only import packages from std or stdx. No third-party imports. No supply-chain risks.
[stdx packages to include, among others]:
gzip, hex, http, json, net, rand
Read Rust has a HUGE supply chain security problem
Submitter's note:
I find the author's writing style immature, sensationalist, and tiresome, but they raise a number of what appear to be solid points, some of which are highlighted above.
It is true that having many dependencies is supply chain attack. However, this is the result of combining the following:
If you want to keep the 2, you're gonna need a lot of dependencies. To significantly decrease the amount of dependencies you're gonna need to drop one of those, there's no other way around it.
If you wanna know what happens when you drop the UNIX mantra look at any discussion about systemd.
If you drop the second one, everybody would have to bring their own glue. Making computers only accessible to Linux gurus that master the "|" operator and study CLI program arguments in their spare time.
I don't know why this article focuses on rust specifically. Every language has this problem. And cargo itself has many ways to mitigate this.
Java and Python projects can be based almost entirely on the standard library because there's so much in there (or packages with minimal/no third party dependencies).
C++ it's not uncommon for the entire code base or the majority of the code base to be internal (and maybe make use of the standard library or a library under the boost umbrella).
The "every language" is largely a "languages that became popular in the NodeJS era" issue.
Java I don't know enough of to say. I never use dependencies in java because I can't be bothered to learn Gradle/maven/eclipse/whatever.
Python I completely disagree. First, I believe all (non-python) libraries are distributed as binaries, no local compilation at all. Which makes the issue of the content not matching GitHub even worse.
Secondly, python is used as a glue language. Most of the time, it's just a way to interact with bindings to a C library. There's no big project that uses only the standard library.
Lastly, in python, whatever you want to import doesn't always match the pip install command. In your code you might say "import MyAwesome69", but the command to install it is "pip install awesome lib". Any malicious actor would just need to publish a python library called "myawesome69" and it would get many people trying to install "awesomelib". You have to know the magic words to install each library. And projects rarely tell you how to install dependencies. Requirements.txt is a joke (if you want to automatically create it, it puts every single installed library on your machine/venv, not just the ones used in your project), but you'll be grateful if the project you want to run provides one. Also, nobody distributes python programs as executables, which means everyone who wants to run it must know the magic words, not just the developers. Moreover, not all dependencies are available through pip. The install instructions might say "install awesomelib", but when you "pip install awesomelib" you pull a malicious library instead of installing the actual awesomelib available via "sudo apt install awesomelib"
I don't usually use libraries in my python scripts, but that's because I use it as a scripting language, they rarely reach 300 loc. If you want to use tl make an actual program. You're gonna pull a lot of dependencies.
C++, like java, I can't speak of, because installing a library was such a pain in windows without Visual Studio that I was never able to. Might explain why they don't use many libraries.