I think that the rust-lang-nursery Github organization[1] is designed to solve part of the trust issue. A lot of the "batteries" crates are in there; `rand`, `futures`, `error-chain`, `lazy-static`, `glob`, `bitflags`, and `log` catch my eye after looking through. In the long run, I don't think that having things like the blessed HTTP library being third-party will be that much of a detriment; at least when I was writing Python, almost everyone I knew used the `requests` library, and nobody worried about it not being part of the standard library.

What sort of maintenance is actually needed though?

Rust promises that existing versions of crates will build and run in the future, assuming the crate is well-behaved and doesn't do anything illegal with unsafe code. That's part of Rust's general stability guarantee.

Maybe "blessed to be maintained" means crates get ongoing critical security fixes? Thanks to Rust, for most crates that's a very low-probability concern. (Obvious exceptions for features like HTTP and TLS that contain their own security decisions.)

Maybe you mean that all kinds of bugs will continue to be fixed and the quality of the crate will keep increasing? I don't think any languages really give you that; they all have standard library features that are effectively end-of-life. A lot of application developers don't even WANT such fixes since there's always a risk of breaking previously-working applications.

So I think it would make sense for the Rust community to commit to a subset of crates for ongoing maintenance, but for probably the majority of crates you could just keep using the exact same version for the next five years with no worries.