crates.io VS rustsec

Dependencies are other Rust packages (called crates) that your project uses. Most of these crates live on crates.io, Rust's central package registry.

Explore Crates: Use crates.io to find libraries for your projects.

Rust? It's built clean from the ground up. The crates.io registry is full of modern, safe, composable libraries. You've got Axum, Rocket and Actix for backends, Leptos, Dioxus, and Yew for frontend, and more. Every library you use follows the same philosophy: safety, performance, and zero tolerance for ambiguity.

I've been ramping up on the embedded Rust ecosystem over the last few weeks. I'm pretty excited about it partly because it makes this aspect of embedded development much more approachable. On https://crates.io I can usually find a driver for whatever peripheral I want to use in my project. And the driver usually implements the embedded-hal [1] interface, so the more I get familiar with that interface, the easier it becomes to implement any arbitrary peripheral into my project. In the event that there does not already exist a crate for my peripheral, I have an extensive ecosystem [2] of open source driver code that I can refer to in order to figure out how to implement the driver.

I think this could help with the "dark art of reading datasheets" problem. E.g. last night I was curious about how the driver for a 28BYJ-48 stepper motor would work, so I looked at the code [3] for its driver and got a pretty good sense of what's going on. If I were to now attempt to read the datasheet, a lot of it would now make sense. In other words I think it's too daunting to read a datasheet and then try to implement code. The way to get comfortable with datasheets is to first look at code and then find the relevant parts of the datasheet.

[1] https://github.com/rust-embedded/embedded-hal

[2] https://crates.io/keywords/embedded-hal-driver

[3] https://github.com/MnlPhlp/uln2003

I often hear this and am confused; not only are things like ['object soup'](https://jacko.io/object_soup.html) possible and straightforward (putting things in collections and referring to them by indices), I never concretely hear why a graph or doubly-linked list becomes uniquely difficult to implement in Rust (and would genuinely be curious to learn why you feel this way). If you needed such data structures anyway, they're either in the standard library or in the many libraries ('crates' in Rust-lingo) available on [Rust's package registry](https://crates.io/)---using dependencies in Rust is very straightforward & easy.

Rust Package Registry (crates.io)

crates.io is the central repository/registry for Rust crates. It's a crucial part of the Rust ecosystem.

Oh dear.

I see Redis Inc. have decided to go full Nagios.

Never go full Nagios.

Though admittedly Nagios' attempt to pull similar assholery wrt CPAN did end up being a source of some amusement to me: http://p3rl.org/Nagios::Plugin

I hope the http://crates.io team react similarly.

Spin 3.0 introduces a workflow for this type of development in the hopes of making it seamless to do things like write a library for some compute intensive task in Rust and use that as a dependency in a JavaScript application. Or perhaps you’re not a Rust developer and don’t feel like learning it overnight? No problem. Fetch a component someone else already built from an OCI registry. Component dependencies can be stored, discovered, and fetched from OCI registries giving you the npm/NuGet/crates.io style experience but for Wasm. Now, I think this particular feature is wild and could go on about it for at least a thesis, but there are even more Spin 3.0 topics to discuss so feel free to dig deeper in the component dependencies documentation here and in the demo later on.

cargo-audit is a simple Cargo tool for detecting vulnerable Rust crates. You can install it with cargo install cargo-audit, use cargo audit and you’re done! Any vulnerable crates will appear below, like so:

Further we use cargo-auditable and cargo-audit as part of both our pipeline and regular scanning of all deployed services. This makes our InfoSec and Legal super happy since it means they can also monitor compliance with licenses and patch/update timings.

Yeah your decade old single header libs get so many audits by comparison.

https://github.com/RustSec/rustsec/tree/main/cargo-audit

https://mozilla.github.io/cargo-vet/

cargo is not npm

PSA: before filing CVEs for other people's projects, file an issue with https://rustsec.org instead

Historically, such serious bugs get communicated broadly and addressed very quickly via security advisory blog posts and on https://rustsec.org.

For known vulnerabilities we have the rustsec vulnerability database. You could have a look over there for inspiration. There's also the related cargo-audit for checking dependencies for known vulnerabilities.

Would be cool if this was also reported to https://rustsec.org/ that way cargo audit could pick up and alert the users about it.

P.S. I also made scanning binaries 5x faster in the latest release of cargo audit.

Thanks to cargo and the community, project maintenance is straightforward in rust. You'll need to install cargo-outdated and cargo-audit:

Use the automated tools to assist you in the maintenance of your projects: rustfmt, clippy, cargo update, cargo outdated and cargo-audit.