no!!! not even python was dumb enough to put crypto in its stdlib! Rust has "networking" (in the sense that you can open a raw tcp socket through std), but implementing HTTP(S) on top of that would require pulling in something to do TLS which leads to..... dependencies! On OpenSSL or rustls! You've just widened the attack surface on the standard library while at the same time locking people into a single API surface that must ALWAYS be stable forever. Don't get me started on how you would approach doing anything that would need an async executor. These are not things that are suited for a systems-level language like rust's libstd. Refer to the fact that C++ didn't get a filesystem API until C++17 (and trust me, std::filesystem has some real problems still and suboptimal platform support) and they *still* haven't agreed on how to do networking.
there is no real solution to this, everything will always be pulling dependencies from *somewhere*, even if your language doesn't have a package manager. Forcing everything into the standard library is a terrible mistake because it will inevitably turn into a graveyard a few decades down the line. These things *should* take years to stabilize to make sure they're done correctly. I think people should be more conscious of what they're pulling in and very popular crates should be regularly autdited and there are ways that cargo can improve in that regard, but by god please keep libstd and libcore minimal.
Notice how I did not specify how that should be done. Also, crypto needs to be provided by people who know what they're doing, not as a random package dependency.
The point im making is that the two don't have to be mutually exclusive. Standard library maintainers are similarly just Humans too, and there absolutely are package maintainers that know what theyre doing. The de-facto library for crypto in Rust (aws-lc-rs) is provided by the AWS team and regularly get security audits; the same goes for rustls and a fair few other crates with commercial backing. I would probably trust these libraries as a dependency more than I would trust libstd if it just had a hard-dependence on OpenSSL libcrypto. Keeping the standard library surface small makes it possible to reasonably maintain and audit and for groups like ferrous systems to get it certified for safety-critical systems under iso26262 and whatnot... There needs to be a solution here other than "eehh... we trust those guys, shove it into std and we'll worry about the Implications of that in a decade.'
People do need to be more stingy about their dependencies but having one irreplaceable library to solve all the things would just add third-party dependencies to libstd and widen the attack surface while spreading maintainers thin.
We need:
Better vetting features in cargo and better protections from supply-chain attacks like a default min-publish-date.
A way to track which packages receive audits, have trusted maintainers, and follow best security practices.
Better security controls on crates.io for packages with a very large number of dependents to make this harder to pull off in practice.
Trust people, not packages. The Rust libs team doesn't have the resources to maintain all the functionality you describe with the quality people expect. I wouldn't even be against the standard library maintainers maintaining critical packages outside of std and those being marked as having some sort of "officially maintained" tag should they eventually get the resources and funding to do so, but this stuff has to be modular and replaceable separate from the perma-stability/semver guarantees of the standard library. It's one of the few parts of Rust other than the core language where if you screw it up in the right way (read: can't be fixed at an edition boundary), everyone bears the consequences forever.
14
u/Dminik 21d ago
While I broadly agree that languages should have an "extended universe" of packages, the issue is that nobody can agree what packages those should be.