Tested a bunch and this is the one I stuck with, at least until I make my own. Once the entries are all right, I use the dare I say industry standard to switch between them:
While the crates ecosystem is certainly not immune to supply chain attacks this over generalization is not justified.
There are several features that make crates.io more robust than npm. One of them is that vulnerable versions can be yanked without human intervention. Desperate comments from
maintainers like this one[1] from just a few days ago would not happen with crates.io.
There are also features not provided by crates.io that make the situation better. For example you could very easily clone the repo and run
cargo vet
to check how many of the packages had human audits. I'd done it if I was on a computer, but a quick glance at the Cargo.lock file makes me confident that you'd get a significant number.
The main issue there is that the maintainer lost access to their account. Yanking malicious packages is better, but even just being able to release new patch versions would've stopped the spread, but they were not able to do so for the packages that didn't have a co-publisher. How would crates.io help in this situation?
FWIW npm used to allow unpublishing packages, but AFAIK that feature was removed in the wake of the left-pad incident [1]. Altho now with all the frequent attacks, it might be worth considering if ecosystem disruption via malicious removal of pacakge would be lesser of two evils, compared to actual malware being distributed.
I'd argue it's more of a culture thing, not technical thing.
In both JavaScript and Rust, it's normal/encouraged to just add a tiny dependency to the package manager. The communities even pride themselves, that they have such good package managers to allow this.
It's this "yeah, there is a crate for this tiny function I need, let's just include it" mentality that makes the ecosystem vulnerable.
People need to be responsible for whatever they include, either pay the price by checking all versions up front, or pay it by risking shipping a vulnerable program that it's much harder to retract than a JavaScript frontend.
I was using "just git" until I realized I've started writing a whole bunch of scripts of various types to recreate ("ad-hoc, informally specified and bug-ridden...") functionality that chezmoi offers out of the box and has already tested in the field.
I've had multiple flaky issues with SQLite (e.g. non-HA Grafana) on Azure Files using NFS v4.1 leading to locked DBs. Perhaps some implementations work, I'm not gonna rely on it or advise others to do so.
When we looked at modernizing our image hosting, it came down to Zot vs Harbor, and we preferred Zot as it looked easier to deploy. Just a go binary with a few environment variables connecting to our minio, what could be easier?
However, when getting the config prod-ready, we started to trip over one thing after the other. First, my colleague was struggling to get the scale-out clustering to work in our container management. Right, use the other deployment way for HA. Then we found that apparently, if you enable OIDC, all other authentication methods get deactivated, so suddenly container hosts would have to login with tokens... somehow? And better hope your OIDC provider never goes down. And then we found a bug on top that Zot possibly doesn't remove blobs from minio during GC.
At that point we reconsidered and went with Harbor.
/it does like this/
reply