rust-lang
RFC: Extended Standard Library (ESL)
This RFC describes an Extended Standard Library (ESL) for Rust.
Please see this document for additional information about fundraising.
I’d like to thank Dirkjan Ochtman (@djc), Adolfo Ochagavía (@aochagavia), Alex Gaynor (@alex), James Munns (OneVariable GmbH, @jamesmunns), Andrew Gallant (@burntsushi), Marco Ieni (@marcoieni), and many others for their feedback and assistance while working on this. My thanks does not necessarily imply their endorsement.
I don't think that this RFC is a good idea for a couple reasons.
The first is, quite frankly, I don't believe that this project will actually improve the situation, but in fact, make it worse. I do not believe that the Rust Foundation will be able to secure more funding to develop the necessary crates than these crates will ultimately be able to get on their own, which I'll get into later. I also believe that by "spreading thin," changes to these crates will ultimately be reviewed less often and lest thoroughly, meaning that it only increases the risk of "supply chain" issues it purports to prevent.
The second is that, flat out, this does not seem to understand the primary reasons why "supply chain" attacks happen, and thus will fail catastrophically to prevent them. The "secret sauce" involves some combination of the below ingredients:
- Widespread use
- High demand for changes
- A small number of maintainers
- A large amount of work per maintainer
Rust mitigates some of these issues, but not really. While unsafe code is heavily scrutinised, a large portion of the Rust ecosystem still relies heavily on external code without such promises. Even the Rust compiler itself, despite strongly working toward "oxidising" its internal dependencies (Rustup recently moved to being RusTLS only, for example), it still relies on massive unsafe code bases like LLVM and Git. While the number of these will decrease over time, I don't expect this to ever fully go away; even if all of the code Rust itself uses is written in Rust, it can still call down to the OS which may not be. And this doesn't even begin to approach exploits which don't even touch unsafe code.
It also particularly points out the XZ vulnerability, which I think is a perfect example that could happen in the Rust ecosystem right now, given the right circumstances. Right now, we have a small number of maintainers on each team which are expected to sign off on a very large number of changes created by anyone, and the Rust foundation has approximately 12 employees at the time of writing, with fewer people actually managing changes to the code itself.
But don't worry! The power of Rust is that many corporations find it in their best interest to hire people full-time as maintainers too!
Do you trust Microsoft, or Amazon, or Google to always hold the community's best interests at heart and not once, never, ever potentially exploit it? Do you think that this does not put them in an excellent position to leverage their community trust for exploiting any number of things, ever, in perpetuity? Do you trust every person in a position like this to properly back out and tell the project what's going on instead of exploiting their position like their employer wants?
Ultimately, there isn't a great solution for "supply chain" attacks that the tech industry wants, because its misdoings are the reason why such attacks exist in the first place. Moving crates into central control and telling people that the foundation has solved the supply chain problem, however, is actively harmful, because it hasn't solved the problem and can't.
I also would love to see more of these crates become supported and maintained by the entire community, but that's not going to happen by just waving a bureaucratic wand. And I think that pretending that the problem is solved will only make Rust a ripe target for these attacks.
Here's a fun question that it would be nice to have an answer to: what happens if an ESL crate depends on a non-ESL crate? Now, you have a crate that's part of the trusted base of vetted libraries which, nonetheless, has the potential to "get xz'd" by its non-ESL dependency. Would ESL crates be forbidden from depending on non-ESL code? Would adopting a crate into the ESL require ESLing its entire dependency tree?
Should this RFC discuss if it will be possible to remove crates from the ESL, or would we allow for duplicate functionally? I recall stdx was hoping to support removing crates, but I imagine it could be very disruptive to the community.
I'm glad to see someone trying to address the problem of supply chain attacks. I think it's an important issue which is currently very difficult to mitigate against.
However I do not think that the presented solution of centralising maintenance of key crates is a good one. I agree with @clarfonthey that the constraint which creates the opportunity for supply chain attacks is lack of available maintainer resources, and that this proposal is likely to reduce the availability of such resources not increase them.
I think the philosophy behind Cargo Vet where vetting/auditing is decoupled from maintaining/owning is the right one, and if there is funding available, I would love to see this model expanded via things like:
- An official, well-maintained version of diff.rs. This website allows people to 1. easily read the code actually published to crates.io (not just the code checked into git which may be entirely different) and 2. see a diff between versions of that published code. To me, these are foundational capabilities for enabling audits.
- Vetting/auditing functionality built into this "diff.rs" UI (e.g. something similar to Github review UI) such that people can easily create audits/reviews via the UI. These would then be saved to a central database.
- Metadata attached to audits with things like standardised categories which denote the depth of review that has been undertaken and the reviewer's confidence level in their review.
- Tooling built-in to cargo which allows users to specify criteria such an "N reviewers (with an optional allowlist of specific reviewers or organisations) must have approved" and/or "there must be less than N negative audits" (perhaps with an additional "warn" outcome that prompts the user to go and read the audits and/or audit the code themselves).
- Pushing crate authors towards MFA
- Expanded support for (emphasis on) signed crate releases (e.g. support for allowlisting certain crates only if new releases are signed by a trusted signing key and prompting for manual verification if a new key is used)
- Directly funding trusted people to spend their time producing audits
Trusting specific crates/publishers is all well and good, but the supply chain attacks I would be most concerned about are when crate maintenance changes hands or a users credentials are compromised. To mitigate against these kind of attacks one really needs each published version to be verified, not just the crate or it's publishers. Given how many users of the really key crates there are, it should be easy to get enough reviews if making one is easy enough.
I think lists of approved crates/authors/auditors/organisations would be useful. But I see no reason why there needs to be a single list. We could perhaps have an "official" rust foundation list that is quite conservative. But also allow other organisations to publish lists which people might decide to either trust wholesale and pick and choose pieces of to form their own lists (e.g. corporations like Mozilla, Google, Amazon, Dropbox, etc; open source collectives like Servo, Linebender, Bevy, etc; and even individuals that may be trusted by the community).
I am very sympathetic to the problem that this is trying to solve.
We recognize the failure of a batteries included std so we rely on the "market" to fix it. This has its benefits but there are also market failures, particularly the burden it puts on "consumers". The cornucopia of options can be overwhelming and put someone in analysis paralysis. This is made worst by the fact that most people needing to decide what to use are likely not qualified to decide what to use and they need guidance. We can provide supply chain management tools like cargo vet but they still require each person to "do their own research".
Providing users with "good enough" starting points that they can diverge from when they encounter specific constraints would be a big help to developers. Standardizing best practices among those (remember the lib blitz?) can help ensure some basic quality and consistency.
I think experimenting in this general direction while also working to improve the overall supply-chain story are good. I worry though that this is trying to be too ambitious in its goals and that (1) this will put too large of a burden on maintainers that participate and (2) this will look like its solving more of the problem than it will and it won't even be able to solve as much of the problem as this comes across.
Overall, I'd prefer to see a softer take, treating this as an experiment, evaluating what the most important goals are and focusing on those, and developing guiding principles for the operation of this experiment. By being an experiment, it does limit the trust element and requires it to be more easily rolled back but I think thats good.
In parallel to this, I would like to see more investment on supply chain story. I know the Founation has talked about efforts several times but I feel no progress is being made. Maybe thats due to how communication is working or because their priorities are different than mine (which can be ok).
While this effort aligns with my own personal opinions about language ecosystems I'm unsure if this is a realistic way to achieve the stated goals.
One of the biggest difficulties when dealing with supply chain security is the asymmetric nature of it. It only takes a single, well crafted, compromised file of code to breach an organization. The vast majority of risk comes from the long tail of 3rd party dependencies and their transitive dependencies. As a security engineer I am far more concerned in my day to day about random helper libraries that touch I/O (say, log rotation) than I am about serde or tokio. I understand that compromise of those large, central dependencies is a worst case scenario with a massive blast radius but I am unconvinced that simply hoisting that functionality under a blessed namespace provides any hard security benefits over the existing status quo. Security is often a function of raw resources dedicated to a problem and the existing eyeballs, momentum, and man power most large rust libraries wield will be a significant hurdle to overcome, at least initially.
That said, I think this RFC does itself a disfavor conflating the efforts to bring, say, encoding support into a blessed implementation with things like ser/de and HTTP and especially so mixing them within the same tranche. Not only will these have differing implementation timelines moving forward but I think the security benefits for blessing some of the "lower level" primitives massively outweigh the benefits of others. This is mostly for a single reason: the transitive dependency explosion that is somewhat unique to Rust. The dependency graphs for most languages (or at least most languages I have experience with), usually start to circle back into the standard library (or at least a defacto standard library) once you go a couple layers deep. This is not true with Rust and is patently obvious whenever you build something non-trivial as even a straightforward project can easily explode to hundreds of total dependencies.
I would advocate this RFC is dramatically scoped down to the following:
* ‘syn’ equivalent
* ‘bitflags’ equivalent
* Encoding support (base64, hex, etc)
* Random number generation
* Error handling support
### Tranche 2: Next step up in complexity/abstraction
* Regular expressions
* Compression (e.g. zlib, zstd) <--- Very much on the fence with this one
In my opinion this is still a very ambitious list and could still be scoped down much further.
I believe these provide the largest cost/benefit ratio for improving supply chain security within the rust ecosystem and success with this list would increase confidence that larger projects could be taken on. I also believe that picking winners in these specific domains will be much less contentious and more straightforward. Last, most of the efforts within this scoped down list have a known definition of done. The scope around providing a default async runtime or HTTP libraries is massive. If my career has taught me anything it is that unwieldy and more importantly undefined scopes are the death of any ambitious software project. And while I think that something like a Rust equivalent to the Golang crypto standard library would be an incredible boon to the community at large I am skeptical that the rust foundation has the raw resources to complete just that single line item with the stated funding.
Separating this out into it's own comment because it might be much more controversial and I care far less about it:
I think absorbing these libraries into a blessed namespace but keeping them functionally out of the std library is a half measure that demonstrates a lack of conviction on the way forward. If we truly want to achieve many of the stated goals I think at least 75% of the list stated here (and the entirety of the list I provide above) should be within the std library proper. Anything else risks creating a scenario that's the worst of all worlds, where these "blessed" implementations bring all the baggage and bureaucracy of working with a language foundation that has many competing interests, with none of the benefits of working with a nimble quasi dictatorship that often exists within the FOSS world or being within the language itself. This isn't a value judgement, it is simply a fact that contributing to a std library (or an officially blessed quasi std library) will usually have a much higher barrier to entry for contribution than 99.999% of all FOSS projects. From a security point of view this is unavoidable, if we want to provide security guarantees around these libraries contributions that would have otherwise been accepted will have to be rejected. At that point you might as well make it formal.
I think absorbing these libraries into a blessed namespace but keeping them functionally out of the std library is a half measure that demonstrates a lack of conviction on the way forward. If we truly want to achieve many of the stated goals I think at least 75% of the list stated here (and the entirety of the list I provide above) should be within the std library proper
We don't want a std 2.0 (cf. python 2/3 breakage). Which means API stability requirements for inclusion in std are very strict and API removal can only happen in exceptional circumstances. If you look at cryptography then that's a constantly evolving field because some of it rests on foundations of sand. And while HTTP has high-level stable semantics its entire innards have been swapped twice in the last 10 years, and since rust is a low-level language we'd likely have to expose those to be useful in many contexts, this seems like too much churn for something that's supposed to be stable.
I think absorbing these libraries into a blessed namespace but keeping them functionally out of the std library is a half measure that demonstrates a lack of conviction on the way forward. If we truly want to achieve many of the stated goals I think at least 75% of the list stated here (and the entirety of the list I provide above) should be within the std library proper
We don't want a std 2.0 (cf. python 2/3 breakage). Which means API stability requirements for inclusion in std are very strict and API removal can only happen in exceptional circumstances. If you look at cryptography then that's a constantly evolving field because some of it rests on foundations of sand. And while HTTP has high-level stable semantics its entire innards have been swapped twice in the last 10 years, and since rust is a low-level language we'd likely have to expose those to be useful in many contexts, this seems like too much churn for something that's supposed to be stable.
Not to mention that in C++, stability requirements (in that case, ABI stability) led to std::regex being slower than shelling out to PHP.
We already have std::sync::mpsc in std. Do I ever use it? No, I used to use crossbeam-channel for the MPMC API that it still doesn't provide, despite now wrapping a vendored copy of that. Now? I use Flume because it also does async.
Whenever I see calls for a "batteries included" std, my intuition is that people are reversing cause and effect... thinking that putting things into std will make them stable, rather than that things having stabilized makes them a candidate for being in std.
It reminds me of how The Art of UNIX Programming from 2003 has parts that aged well (the things that were already solved problems) and parts that aged poorly (eg. Recommending XML for structured file formats because JSON and YAML weren't even two years old yet. Recommending a now-obscure protocol named BEEP for what XMPP seemed likely to do and now WebSockets are doing. Recommending DocBook XML for what is now being done by tools like Sphinx and mdBook, despite AsciiDoc providing a Markdown/ReST-like lightweight syntax that maps 1:1 to DocBook. etc.)
Making BEEP into RFC 3080 didn't drive adoption because standardization doesn't magically overrule all other concerns.
We don't want a std 2.0 (cf. python 2/3 breakage)
Not to mention that in C++, stability requirements (in that case, ABI stability) led to std::regex being slower than shelling out to PHP. We already have std::sync::mpsc in std. Do I ever use it? No, I used to use crossbeam-channel for the MPMC API that it still doesn't provide, despite now wrapping a vendored copy of that. Now? I use Flume because it also does async.
There is always the option of not repeating the mistakes that languages have made in the past. I'm not trying to be trite but to me these aren't necessarily arguments against expanding or changing the std library, these are arguments against expanding or changing the std library without long term resource commitments and a well known plan. I would also caution people against conflating resource constraints with technical constraints. I do think whatever your thoughts on Go as a language, I think the Go team has conclusively proven that given enough resources and direction these are very surmountable challenges by just investing in quality maintenance work.
But that obviously doesn't actually address these concerns for us as the Rust Foundation has significantly fewer resources than Google. To me this is an even stronger argument for using inclusion to the std library as a litmus test. If the rust foundation doesn't want to commit resources to including something in the std library (or alternatively, they don't believe such a thing belongs there) then why are we committing resources to an ESL for that same code? If the answer is just security it's my personal opinion that sponsoring regular security audits would be infinitely more cost effective. Otherwise the ESL will incur large costs with very little benefit.
Please correct me you disagree here but again I just don't see a way these ESL libraries can achieve this middle ground where they are stable, trusted, reliable, and secure but still able to be nimble, make breaking changes, and iterate fast without dedicating roughly the amount of resources required to include that same code into the std library.
Edit: In case it's not clear, my general thrust here isn't that these things should be in the std library, just that long term blessing this code has roughly the same resource commitments as including them in the std library, and if we don't want to do that then we shouldn't include them in an ESL either.
Regarding the question of whether this needs to be a Rust project thing, I don't think it does. The idea was to propose it to the Rust project first and if folks decide that doesn't make sense, then we can look at potentially organizing something outside of the Rust project.
I'm primarily concerned with mitigating the problem of there being too many dependency sources for the average Rust program. Whether or not this particular proposal is part of how that happens is not as important. If conversation about it leads to other improvements to the supply chain security problem that's a great outcome.
I think this RFC is conflating 2 different concepts:
- Is this library going to burn your house/company down?
- Is this a good tool for usecase X?
In the real world, we have bodies like Underwriters Laboratories that focus on (1) while completely ignoring (2).
These are very different concepts. A library that has a hard-to-use API is not going to burn your house down. If there are 2 competing libraries, one of which is popular for projects started 5 years ago, and another one is popular for projects started 5 weeks ago, it makes sense to certify that both libraries will not start fires, even tho one of them is probably not recommended for new projects.
[As a separate problem, if a human group with an horse in the race, such as the Rust Project, is going to start putting stamps on libraries, this will cause drama for well-known human reasons].
@pbdeuchler
For std inclusion - the Rust std is closer to Python's builtins than to Python's standard libraries. std is versioned along with the compiler, which makes it annoying for people to control updates of it, which means that for everything that does not want to "live with the compiler", it probably makes more sense for it to live in a rust-lang/X non-std library than in std
Please correct me you disagree here but again I just don't see a way these ESL libraries can achieve this middle ground where they are stable, trusted, reliable, and secure but still able to be nimble, make breaking changes, and iterate fast without dedicating roughly the amount of resources required to include that same code into the std library.
@pbdeuchler I think the idea is to have a set of libraries that are "trusted, reliable, and secure" but that are not 100% stable and can make breaking changes. Probably these libraries wouldn't be really iterate fast or nimbly but they would be able to make breaking changes with major version release if needed.
I'm primarily concerned with mitigating the problem of there being too many dependency sources for the average Rust program.
This seems like ~rearranging the deckchairs on the titanic~ musical chairs. There are finite resources to review things. A lot of focus already is on the core ecosystem. Formal verification, fuzzing and all that. And it's still not enough. And yet every big project will need stuff outside the core set. Maybe an OIDC client or some SNMP or XMLRPC parser (ugh). In the end everything ought to be reviewed. The number of people it comes from doesn't really change much about that.
I think absorbing these libraries into a blessed namespace but keeping them functionally out of the std library is a half measure that demonstrates a lack of conviction on the way forward.
Just picking up on this point, I think it's important to recognise the current architectural reality of std:
- it cannot be built by its users,
- is not a crate so cannot be [patch]ed, shimmed, poly-filled, ported, or forked,
- is not separately versioned and so can never break,
- has a weird and unique relationship with its compiler,
- has a weird and unique relationship with its dependencies,
- is supported on stable platforms that it arguably shouldn't be (eg, functions that just panic statically, are not documented to do that, and can never do anything different),
I realise some of those issues are being worked on now, and I hope that work is successful.
But the idea of permanently stabilising things into std up to the complexity of a HTTPS client seems like a non-starter on this backdrop. And I think that's why this RFC does not even go near that idea.
But the idea of permanently stabilising things into
stdup to the complexity of a HTTPS client seems like a non-starter on this backdrop. And I think that's why this RFC does not even go near that idea.
As a libs-api member, I very strongly agree. I don't ever see "HTTPS client" as being a viable thing that will make it into the Rust standard library.
To a first approximation, APIs added to std have to live forever. It is very easy to under-estimate the profound impact that has on API design and what we're willing to add to it.
If you want a standard library with every feature you can imagine, then you should use Python, C#, Java, or any number of more high-level languages. A systems-level language like Rust has no business trying to package things so far outside core functionality in its standard library. There are already places in the standard library where certain trade-offs are made that favor one use-case over another—to the detriment of overall development in that use-case.
Just my 2¢.
@arielb1 @nicoburns I think we are all in violent agreement here... I'm not advocating for putting unstable APIs in the std library. But 75% of the domains in this RFC are well known and stable, those I would advocate for putting in the std library. The remaining 25% that are external "blessed" libraries, however, will still require effort commensurate with any std library work. The rust foundation should be ready to commit to spending those resources long term if it wants to go down this path (which I support).
But regardless I am worried I have created a thread of conversation that distracts from the main proposal, I did not wish to re-ignite a debate about std library inclusion... happy to concede this point in that case.
We don't want a std 2.0 (cf. python 2/3 breakage)
Not to mention that in C++, stability requirements (in that case, ABI stability) led to std::regex being slower than shelling out to PHP. We already have std::sync::mpsc in std. Do I ever use it? No, I used to use crossbeam-channel for the MPMC API that it still doesn't provide, despite now wrapping a vendored copy of that. Now? I use Flume because it also does async.
There is always the option of not repeating the mistakes that languages have made in the past. I'm not trying to be trite but to me these aren't necessarily arguments against expanding or changing the std library,
The problem is that clairvoyance is an unsolved problem. Being extremely conservative about how much stuff is baked into the library you've committed to never having a "Python2 to Python3" transition on is "not repeating the mistakes that languages have made in the past".
these are arguments against expanding or changing the std library without long term resource commitments and a well known plan. I would also caution people against conflating resource constraints with technical constraints. I do think whatever your thoughts on Go as a language, I think the Go team has conclusively proven that given enough resources and direction these are very surmountable challenges by just investing in quality maintenance work.
Personally, I think at least half of Go's solution to it being an insurmountable problem is WONTFIX NOTABUG-ing the problem out of existence. It's much easier to design an API which lasts if you just define the unsolved parts as out-of-scope.
Go is what you get when people think all C needed is garbage-collection, a perforated implementation of memory safety, a concurrency model that was all the rage in the 1990s, and a strong anti-FFI belief that "cgo is not Go" because things like extending Go-style easy cross-compilation to FFI is hard work that requires cooperation with people like the LLVM or GCC developers.
But that obviously doesn't actually address these concerns for us as the Rust Foundation has significantly fewer resources than Google. To me this is an even stronger argument for using inclusion to the std library as a litmus test. If the rust foundation doesn't want to commit resources to including something in the std library (or alternatively, they don't believe such a thing belongs there) then why are we committing resources to an ESL for that same code? If the answer is just security it's my personal opinion that sponsoring regular security audits would be infinitely more cost effective. Otherwise the ESL will incur large costs with very little benefit.
Please correct me you disagree here but again I just don't see a way these ESL libraries can achieve this middle ground where they are stable, trusted, reliable, and secure but still able to be nimble, make breaking changes, and iterate fast without dedicating roughly the amount of resources required to include that same code into the std library.
I can agree with that. Every time some kind of stdx has come up, my perspective, has always been "OK... but where is this extra manpower gonna come from?"
Edit: In case it's not clear, my general thrust here isn't that these things should be in the std library, just that long term blessing this code has roughly the same resource commitments as including them in the std library, and if we don't want to do that then we shouldn't include them in an ESL either.
I disagree that they should be in the standard library for the same reason that, when you look at things like accessing members of collections, C++ reveals itself to be three different languages in a trench coat, refusing to admit that C++ failed and C++ v2.0 failed by disguising the fact that they underwent a Python2 vs. Python3 vs. Python4 transition as, instead, a "Python 2.x has urllib and urllib2 in the standard library" situation.
I think there's a nugget of value in this RFC: specifically a set of "higher standards" that crate authors can choose to follow, where those standards are agreed upon in a centralized way.
These parts on the other hand seem actively harmful:
- Moving crates to a central github org is pointless and creates a single point of failure.
- Naming crates after ESL creates harmful churn for users of the crates, and the idea that crates will be created to be ESL crates from the start is pure hubris, and will lead to a ton of garbage ESL crates.
I think what could work would be a decentralised trust model:
- Any organisation can announce on a crate's crates.io page "I trust this crate revision". The amount of scrutiny in this review would be entirely up to the organisation.
- As a user, I can use a
cargo auditlike tool to find dependencies that are not trusted by any of a set of reviewers that I trust.
With this approach, any person or organisation can create a "brand" around their crate reviews.
Optionally, a Rust ESL team could maintain a list of "trusted reviewers". They would set the criteria for what warrants inclusion in this list, but might include:
- Having a certain number of reviews.
- Being independent of other reviewers in the list.
- Having certain standards of review.
- etc.
Following from that, any crate revision which has been given the seal of approval by at least two or three different reviewers on this list would be eligable to be part of the ESL.
Notably in this setup, the ESL team is concerned only with policy making and maintaining this reviewers list, and is freed from the more time consuming work of reviewing the many crates involved. Furthermore, it gives large companies which might already be doing some level of review of their dependencies the ability to feed back that value into the ecosystem, without ESL crates being exclusively corporate focused.
I see a philosophical problem with blessing a subset of dependencies for writing backend code. Rust will suddenly look a lot less like an all-encompassing replacement for C/C++ and instead more like a supped up Go for writing APIs. I don't want to see this.
Just to pick a random one, why have base64 in std? I have been writing Rust since 2013 (since 2016 professionally), and I haven't serialized/deserialized something as base64 once for work.
To my machine learning/scientific computing eye, that's something a backend server cares about. Not to mention, there are multiple base64 libraries with different trade-offs.
I see a philosophical problem with blessing a subset of dependencies for writing backend code. Rust will suddenly look a lot less like an all-encompassing replacement for C/C++ and instead more like a supped up Go for writing APIs. I don't want to see this.
I think that much of it is that backend servers are where the "Underwriters Laboratories" stamp is most important. For other sorts of programs there are generally other methods that prevent them from burning down your company (people might also want a "safe for embedded" stamp, but that stamp would have different regulatory characteristics than a "safe for backend" stamp).
But I agree that the existence of multiple versions of base64 decoders (my fairly simple Cargo.lock has 3, 4 if you count different versions of base64) is a pretty good argument against having a decoder in libstd, but also a pretty good argument for having a way to "bless" them all.
I agree. I expect the Rust project to have negative alpha when it comes to finding "the best crate for usecase X". Also, I believe that "find the best crate for usecase X" is best done by an algorithm - such as lib.rs, or a search engine/LLM. It might make sense for rust-lang.org to link to one.
Which does not detract from the Rust community benefiting from a way of knowing that a crate is "reliable", even if not necessarily "the right tool for a particular job", along with a path for crate authors to be able to get their crates to reliable (of course, the Rust Project considering a crate to be "reliable" does not mean that it is owned by the Rust Project. For example, I am quite sure that the Rust Project regards Tokio as a highly reliable crate, but Tokio is run by a separate project).
Moving crates to a central github org is pointless and creates a single point of failure.
Giving maintainers of popular crates the option to put their code in a Github repository with certifiably high security standards and coupling the code on git to the code on crates.io somehow (while letting the maintainer have complete control over the code except in "actual security breach" situations. I mean, Github owns the git repository and the Rust Foundation owns the crates.io index even today and they might act even today in the case of an actual security breach) rather than having maintainers needing to figure out by themselves how to secure github.com/jsmith123/my-crate, sounds to me like a good enough idea if it can be done in a reasonable way.
Of course, if maintainers already have some sort of git repository that they know how to secure, they might not need this help, and the Rust Project should not have a "let us own your repo OR ELSE you won't get a pretty badge" system.
Giving maintainers of popular crates the option to put their code in a Github repository with certifiably high security standards ...
The core benefit of that is that certification is measurable. It would be significantly more useful to be able to verify that those standards are met. Putting the source into a GitHub organization is not the only way to make that happen.
Giving maintainers of popular crates the option
Yeah I'm not opposed to giving the option, as long as it's not a requirement.
As a rule, rust code outside the standard library winds up more "opinionated" than the standard library, like even the getrandom crate in rand, and/or more more featurefull. In particular, the standard library tends more towards a simple baseline targeted at most devs, but it absolutely doesn't care if your niche use case require that you fork one of the stc functions.
Those are natural explorations, but you really do notice a big stylaistic difference between std and other crates.
Would we have less bikeshedding over preferences if we call this "officially endorsed libraries" instead of "extended standard library"? The term ESL gives the following (possibly untruthful) impressions:
- that ESL will be shipped with rustup
- that ESL correlates with msrv
- that ESL is maintained by T-libs or equivalent
- that ESL is an official recommendation over non-ESL libraries
- that the barrier for a v2 in an ESL library is very unlikely
Would we have less bikeshedding over preferences if we call this "officially endorsed libraries" instead of "extended standard library"?
- that ESL is an official recommendation over non-ESL libraries
for me, "officially endorsed libraries" gives that impression too, so if you're trying to avoid it, you'll want a different term.
