I'd say that this is more of a culture thing rather than a language thing.
I'd say that this is more of a culture thing rather than a language thing.
2) Improve the metadata that describes a crate so that it is easy to tell if a crate should be used. For example, is the crate beta quality? Was a serious error found in the crate and it needs to be marked as "not safe"? Is it a Long-Term Support release? Etc.
3) As a culture, disallow trivial crates. No "is-odd" or similarly low effort crates. These just add bloat since the have so little functionality compared to their overhead. If your crate's toml is larger than the crate's code, you are doing it wrong.
So a language could:
- identify a blessed set of packages that don't imply separate trust relationships (a stdlib, or packages maintained or audited by the language team)
- require strong security practices and/or trust metrics from package authors
- clearly expose the full list of authors implicitly trusted by a requirements file
- offer community auditing tools, such as reproducible builds if delivering compiled files, web of trust tools, or diff tools
- run internal tests for suspicious packages (and don't talk about them)
If you frame the problem differently the solutions might be different, but I suspect there would still be a bunch of options.