While the thinks mentioned are a thing, his recommendations and interpretation of them seems often strange for me.

> Typosquatting

Well known problem of more or less any open repo, namespaces do not solve it, they just shift the problem, maybe even make it more complex.

> Misleading name

Again not cargo specific and not specific to flat namespaces either.

Namespaces help with first party packages from the same authors (but then it's not too hard to check the authors, but annoying; Annoying is insecure). But namespaces do not help with 3rd party libraries. I.e. many (most?) `tokio-` libraries are 3rd party libraries made to work with tokio, not libraries from the `tokio` authors.

> Transitive dependencies

Again something inherent to all package managers.

Through some ecosystems like npm are worse due to using more smaller packages.

In my experience while most rust crates have many dependencies most of them are to the same set of packages (like thiserror, anyhow, serde, etc.).

Anyway trying to avoid unnecessary dependencies is generally not a bad idea.

> “x.x.1” Update

Basically: If you update a dependency you update a dependency, surprise.

Anyway using a `=` dependency is a anti-pattern which produces an endless amount of headaches and incompatibilities especially with libraries using `=` imports. There is a reason lock-fiels exists and `cargo update` doesn't run by default.

> Malicious update

This point make no sense as:

- cargo is not specific to the version control system you use it has some helpers for some vc systems, but that's it.

- git tags are settable arbitrarily (and can be "moved").

- You get the source from crates.io, not GitHub.

So the only way this can be a security vulnerability if you believe that reviewing not the source you use but source code from a different source is a good idea, while also trusting git tags while not fully trusting the author who sets the tags????

Just review the source code which you use, uploads to crates.io are immutable and you can download and read them.

> Run code before main

Neet to point it out, but not specific to either rust and even less to cargo/crates.io. It's specific to the systems binary file format and how binaries are executed.

> principles of Rust is no life before main

A design principal for the rust language, not a security statements.

Anyway review the source code you use, not source code form a different source you believe should be the same (unspecific of rust).

Rust could also improve on this by warning if (transitive) dependencies links to .ctor or similar.

> Malicious macros

Code generation is an interesting aspect to analyze across languages. Most have it, some like rust at compiler time and first calls, other at compiler time but second class and others at runtime (e.g. Java reflections).

It's definitely an area where rust has a lot of potential to improve (e.g. default-wasm sandbox most proc-macros or similar).

It's also unavoidable in some cases (e.g. building external dependencies).

Additionally I would argue you probably could find a way to have code which somehow allows you to start running code when it's compiled due to you crafting the code in a way which triggers buffer overflows and similar in the underlying compiler (e.g. LLVM).

You also tend to run tests...

So theoretically you always should sandbox your IDE/project, even if you develop for a language which doesn't has compiler time code generation.

As a side-note vscode ask you if you trust a project you open, if not it will change some settings for the project and rust-analyzer can be configured to no run build-scripts and proc-macros. (I haven't tested if not trusting automatically also makes rust-analyzer not run things.).

> a bigger standard library would reduce the need for external [..]

no, it doesn't reduce the need. See python. Or see how even some features in rusts standard library are frequently not used but instead externally libraries are used, e.g. parkinlot or crossbeam.

Similar having 10 instead of 1 dependency might not decrease security if that 10 are a bundle from the same author in the same CI and have not (relevant) more code then if they where just 1 dependency.

What you want is reducing the number of trusted entities (!=not packaged) and trusted lines of code.

So having a group which manages a set of widely used packages with tight security would roughly be as helpful for the problem as having a bigger standard library, but much more practical. To some degree the rust nursery was going in that direction (but didn't reach that goal).

> Rust supports git dependencies.

It also allows pinning versions in Cargo.toml, pinning versions in lock-files and is immutable.

Git dependencies are prone in making you miss security updates, similar 3rd party audits are likely done on the code uploaded to crates.io, not the one on GitHub.

If you want to review all dependencies, and make sure to use them etc. then it's probably best to vendor all of them, and set thinks up so that your dev system can only see/reach vendored packages, while from time to time updating them based on crates.io and on diffs of the crates.io uploads (not GitHub).