Can crates owned by the rust-lang-owner user, or some of many rust-lang org teams, be considered somehow "official" or endorsed by Rust? Equivalent of the extended standard library?
I wonder how much attention is paid to ownership of the crates, and if crates with rust-lang owners can be considered official and/or more trustworthy. Does this ownership imply some level of assurance?
No, we have plenty of old crates lying around that are unmaintained, e.g. conduit
Various crates are also owned/maintained by different teams or de facto by one or two individual volunteers who may be able to publish unilaterally, so there's no safety against insider threats. Perhaps there is a quantum more reliability because ultimately there's someone else with the necessary credentials (the infra team I think) who can jump in and take over if some emergency arises, but that doesn't mean that every crate is actively monitored for quality.
maybe only the crate that could be extern crate directly could regard as an official crate
#[no_std]
extern crate alloc; // alloc crate is usable without adding it in Cargo.toml, thus it is official
... // define a global allocator as alloc required
... // define an entry that calls main
fn main(){
...
}
I'm asking, because Rust users and especially not-(yet)-users often express anxiety about using 3rd party crates from crates-io. People coming from "batteries included" languages expect libstd to have more stuff.
There's a good reason to keep libstd small, but Rust could have an officially blessed extended standard library in the form of rust-lang-owned crates. What matters is not the exact way of obtaining the code, but having the same stability and supply-chain-security guarantees as libstd.
The concept of "officially blessed" crates has come up since the 1.0 release. I can't speak for the libs team today, but at least historically we were very reticent to pick winners and losers in the ecosystem. I'm not aware of any language that tries to do something like that.
The bulk of rust-lang owned crates are only there because they used to be in the standard library and were cut out in the preparation for 1.0.
There is a policy for how crates managed by the rust-lang organization are to be considered: https://forge.rust-lang.org/policies/crate-ownership.html. However, most have not been updated to include this information.
I would separate out the words "official" and "endorsed". Many crates are "officially" part of the Rust project. I think whether or not they are endorsed is a different question, and it all depends on context. I would say, if you want a blanket assumption, that assumption would be "no".
I don't mean picking winners from the whole ecosystem, just securing the review and deployment process of libc, rand, cc, cfg-if, and the few other crates that already live in rust-lang org repositories and are owned by rust-lang-owner user.
One counter example would be C++ and Boost, where a lot of things added to C++, especially C++11, came from Boost before being standardized.
I don't see importing third party designs into the standard library as the same thing - we do that plenty as well.
"The Rust Libs team proclaims that people should use tokio instead of async-std or smol" is what I am saying we did not want to get involved in.
Is the libc crate considered part of the Rust project?
I'd say yes it is, all three of libc + stdarch + compiler-builtins frequently need complicated change sequencing with the compiler.
What exactly do you mean by "securing the review and deployment process"? The rust-lang org requires 2FA on GitHub accounts (which are crates.io accounts). What else?
I recently published a libc release and did so with a crates.io token I had lying around on my filesystem. I was negatively surprised by that and deleted my token because that's very much not 2FA. I have a hardware security token but afaict it's currently not possible to use that for crate publishing.
So currently a single developer or one who has his credentials stolen can release at least some of the rust-lang crates to crates.io. This is a much lower bar than for rustc/std releases.
rustc itself pins all its dependencies, so that's less of a problem for rustc itself. But it means that's very much not the same supply chain.
The rust-lang/rust repo has a mandatory code review process set up, which makes it hard for any individual to add whatever code they like. I assume that stable releases of Rust/rustup also have some processes and access controls that limit who can make the release.
OTOH most crates that live in rust-lang org repos and/or are owned by rust-lang-owner, also have other individual owners. The other owners could use their private access tokens to publish any code at any time. There doesn't seem to be a locked down automated release process for these crates. When individuals make releases, it's hard to tell whether these crates are meant to be treated as seriously as rustc releases, or are they hobby projects of people who just happen to belong to rust-lang org.
There are very popular crates that have a home in the rust-lang org GitHub, and are maintained by members of the Rust project. On lib.rs I'd like to be able to tell users that "these crates are as good, safe, and reliable as libstd itself" (e.g. there's no randomness in libstd, but there's rand, and I'd like to assure users that using the rand crate is as good as having std::rand), but based on responses in this thread, it's not that simple.
It's definitely not that simple, and crates in github.com/rust-lang have wildly varying standards ranging from "if this breaks it's a critical event" to "maybe someone pays attention once in a while and hits merge, maybe", if that much. Anything more than that would be on a crate-by-crate basis.
As a weaker version, you could maybe grab https://github.com/rust-lang/rust/blob/1.79.0/Cargo.lock (or use an sbom, once available) from each compiler release to mark which versions of crates the compiler uses, as a weak signal.
I'd say that any crate within the rust-lang GitHub org is part of the Rust project. But that does not have any qualify guarantees.
The lockfile is updated by many different people, and sometimes automatically by GitHub actions. I don't think there's any quality or security assurance there [1]
It'd be nice if rust-lang used cargo-vet.
I guess it could be used in a sense that if there was malware in any of these crates you've got it via rust release anyway 
âŠī¸
Tidy has a list of allowed dependencies for the standard library, rustc and a couple of tools. It doesn't check all tools that are part of the main rust repo though. And there is indeed no checking of the actual source code by a maintainer.
That's a specific case where I wish you would 'pick a winner'.
I have a large project based on async-std, a choice made at the start based primarily on the fact that it's API is more familiar. Now I'm facing big struggles every time I add a new async dependency.
The lack of crucial traits in std means many libraries have to choose what runtime they will support. Some provide support for multiple runtimes, but that is quite an ask so I understand why most go with what is the most popular by a huge margin.
This experience has left me feeling strongly that there should be an async runtime maintained by the rust project. Not part of std but an officially supported crate. That does not preclude others from providing specialised runtimes for specific use cases (eg. Embedded) but at least it would provide a good starting point for the vast majority of users.
Async-std was a perfectly good choice for us based on its performance and functionality - the main problem has been the lack of easy interworking with dependencies.