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.
cargo imports over 400 crates.
crates.io has over 500 transitive dependencies.
…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.
I keep reading about the “supply chain.” I will just leave this here. https://www.softwaremaxims.com/blog/not-a-supplier
I’ve read that. Defining a supplier as someone with whom you have a direct business relationship with seems intentionally narrow in an unhelpful way that just further muddies the waters around the issue at hand. Making something generally available to others means that you’re supplying others with that thing. While it’s true that you may have no further obligations to those that receive your software, the person receiving the software needs to evaluate their risks around using and depending on that software regardless of the existence of a business relationship with the supplier. Hence supply chain risk evaluation is always necessary. That risk evaluation, or lack thereof, can result in a security problem. These problems can propagate widely within a software ecosystem. This is true with and without the existence of direct business relationships between suppliers and recipients of software.
The whole article can be summarized by saying if you want support services related to the software written by others, negotiate a support agreement related to that software. That has nothing to do with taking a wide or narrow interpretation of the word supplier.
Exactly. A “supply-chain attack” is a very real thing in software, and it doesn’t really matter whether you consider yourself a supplier, the fact remains that something a product relies on had a security vulnerability that resulted in the product getting pwned. Nobody should be claiming that the unpaid developer maintaining that library that resulted in the vulnerability is somehow at fault in any legal sense because the license specifically states there is no warranty etc, but it is useful to point to that library as having that vulnerability to let other organizations know where the problem originated so they can either fix or replace it.
I have a better idea that can solve everyone’s problems. Businessnes make their own libraries and keep it closed for themselves. The FOSS community will use it for FOSS stuff. I’m more of a libre person that.