crates.io
cargo-crev
crates.io | cargo-crev | |
---|---|---|
673 | 57 | |
3,224 | 2,191 | |
1.5% | 0.7% | |
10.0 | 7.2 | |
7 days ago | 10 days ago | |
Rust | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
crates.io
-
Getting Started with Dependency Management in Rust Using Cargo.toml
Dependencies are other Rust packages (called crates) that your project uses. Most of these crates live on crates.io, Rust's central package registry.
-
Getting Started with Rust: A Modern Systems Programming Language
Explore Crates: Use crates.io to find libraries for your projects.
-
Beyond TypeScript 🚀
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.
-
Online Embedded Rust Simulator
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
- Comente o porquê, não o quê
-
Static search trees: 40x faster than binary search
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.
-
What is Rust, and What is for it?
Rust Package Registry (crates.io)
-
My First Publish to crates.io (and cross compilation)
crates.io is the central repository/registry for Rust crates. It's a crucial part of the Rust ecosystem.
-
Redis is trying to take over the all of the OSS Redis libraries
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.
-
Introducing Spin 3.0
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-crev
- Cargo-crev – cryptographically verifiable code review system for Rust
-
A tale of several distros joining forces for a common goal: reproducible builds
It unfortunately doesn't help in cases like this. Reproducible Builds gives you a trusted path from source to binary, but it doesn't help with backdoors in the source code/build instructions.
For that we'd need some sort of source code reviewing effort like https://github.com/crev-dev/cargo-crev implements. I've started whatsrc.org to keep track of the source code inputs we're putting into our computers (that would benefit from reviews), but the conclusion is also somewhat "it's too much".
-
Hard disk LEDs and noisy machines
In other cases it may be more documented, such as Golangs baked-in telemetry.
There should be better ways to check these problems. The best I have found so far is Crev https://github.com/crev-dev/crev/. It's most used implementation is Cargo-crev https://github.com/crev-dev/cargo-crev, but hopefully it will become more required to use these types of tools. Certainty and metrics about how many eyes have been on a particular script, and what expertise they have would be a huge win for software.
-
Rust Without Crates.io
The main problem the author is talking about is actually about version updates, which in Maven as well as crates.io is up to each lib's author, and is not curated in any way.
There's no technical solution to that, really. Do you think Nexus Firewall can pick up every exploit, or even most? How confident of that are you, and what data do you have to back that up? I don't have any myself, but would not be surprised at all if "hackers" can easily work around their scanning.
However, I don't have a better approach than using scanning tools like Nexus, or as the author proposes, use a curated library repository like Debian is doing (which hopefully gets enough eyeballs to remain secure) or the https://github.com/crev-dev/cargo-crev project (manually reviewed code) also mentioned. It's interesting that they mention C/C++ just rely on distros providing dynamic libs instead which means you don't even control your dependencies versions, some distro does (how reliable is the distro?)... I wonder if that could work for other languages or if it's just as painful as it looks in the C world.
-
I don't care about cookies” extension bought by Avast, users jump ship
For instance, the worst company imaginable may be in charge of software that was once FOSS, and they may change absolutely nothing about it, so it should be fine. However, if a small update is added that does something bad, you should know about it immediately.
The solution seems to be much more clearly in the realm of things like crev: https://github.com/crev-dev/cargo-crev/
Wherein users can get a clear picture of what dependencies are used in the full chain, and how they have been independently reviewed for security and privacy. That's the real solution for the future. A quick score that is available upon display everytime you upgrade, with large warnings for anything above a certain threshold.
-
I think there should be some type of crates vertification especially the popular ones?
The metrics on crates.io are a useful sniff test, but ultimately you need to review things yourself, or trust some contributors and reviewers. Some projects, like cargo crev or cargo vet can help with the process.
-
[Discussion] What crates would you like to see?
You can use cargo-geiger or cargo-crev to check for whether people you trusted (e.g. u/jonhoo ) trust this crate.
-
Pip and cargo are not the same
There is a similar idea being explored with https://github.com/crev-dev/cargo-crev - you trust a reviewer who reviews crates for trustworthiness, as well as other reviewers.
- greater supply chain attack risk due to large dependency trees?
-
Why so many basic features are not part of the standard library?
[cargo-crev](https://github.com/crev-dev/cargo-crev) looks like a good step in the right direction but not really commonly used.
What are some alternatives?
Cargo - The Rust package manager
stackage - Stable Haskell package sets: vetted consistent packages from Hackage
trunk - Build, bundle & ship your Rust WASM application to the web.
crates.io-index - Registry index for crates.io
docs.rs - crates.io documentation generator
rustsec - RustSec API & Tooling