"The solution to rust's supply chain woes is me stealing some code and vibe coding the rest" is truly one of the take of all time.
And in general, people pointing at Rust "limited" stdlib (it's only limited compared to Python) as one of the big issue and risk with rust are, in my opinion, misguided. You will never make an stdlib big enough to remove the need for external dependencies. It also creates a bunch of other problems. Actually, to take Python as an example, some functionality being in the stdlib have created a bunch of issue over the years since you can't just introduce breaking changes in an stdlib as easily. Look at urllib2/3 or xml in python. In the end, almost everyone ends up using requests and lxml instead.
There are many issues that need to be dealt with to mitigate supply chain attacks. A bigger stdlib or an "stdlib-extended" a la Boost, is not one of them.
Also, specifically for Rust, many people run in a no-std environment (anything sized constraint for the most part). So another stdlib would do nothing for them.
And that's a BIG deal because Go gives you single binaries with a stdlib that allows you to hit the ground running in a serious manner.
For example, making API calls which is the sort of thing many here do for their bread and butter. Everything you need to do can be don in Go stdlib without opening yourself up to supply chain vulnerabilities or having to choose which crate or having to keep track of crates versioning.
It just looks like stdx has copied stuff from crates and put it in a git repo.
It feels like this is worse than a package manager? As in why would I trust a random git repo to keep things up to date over the officially published channel?
Plus, with forks anyone can publish a commit accessible from the main repo, so one could disguise a malicious version of stdx by forking the repo, pushing their charges, then setting the rev:
base64 = { git = "https://github.com/rust-stdx/stdx", rev = "<sha1 of malicious commit in fork>" }
This comment needs to be higher up. The author styles themselves as a cybersecurity expert, but makes the fundamental mistake of assuming that they’re trustworthy and we’d trust them no questions asked. Software security isn’t based on blind trust like this. I’m surprised an expert can’t see that.
The other reason I don’t trust them is because this repo is 100% AI slop, even for crypto code. He posted it on /r/rust where every comment was highly negative - https://www.reddit.com/r/rust/s/4I4Xc7x7ec. The thread was removed by a moderator with the note:
Please, stop posting articles from kerkour.com.
The blog has been on a downward spiral for years, it's doomed, let it go.
Yeah that confused me for a second too. I think they're talking about stdx as a single package, even though it contains multiple crates. If you wanted to install a crate from stdx specifically, you'd use this git URL but if you wanted any other package, you'd use another git URL controlled by that project.
So as I understand it, they're not suggesting that we pile many packages into 1 git repo as a sort of pseudo-crates.io, they're just promoting the fact that you can install a package directly from a git URL, rather than using a crate name on a registry.
What seems weird about that model to me is that dependancies will not sync between these individual packages. If package A chooses the canonical git URL for package C, and package B uses a self-hosted version of package C instead, you have two versions of package C.
The author is trying to make "stdx" a thing, and content like this (I'm not dunking on it) is what you write when you're trying to reinforce the idea that it's a thing.
The big question about this project isn't its distribution, it's the core question it posed when it was first announced: are Rust developers going to seriously entertain an alternative "standard library" curated by one developer.
It's quite an, ahem, interesting mix of libraries, including three csv libraries, hyper_utils (but not hyper itself), and a ton of copied crates from other maintainers.
I hope the author has a good way of updating these with upstream fixes (some look out-of-date already), otherwise you may replace one security issue with another.
And the name stdx has been taken on crates.io, more than 11 years ago which can also be equally confusing.
As far as I understand, this is purely a result of lack of maintainer resources. Apparently, nobody has been bothered enough by this to contribute the relevant changes.
Keep in mind that all of rustc and libs development takes place on Github.
Yes, unfortunately it is true. Sad, but I could live with that.
What in my opinion is unacceptable is that it requires you to give permission to "read your organization and team membership and private Projects".
I made a separate GitHub account (weinzierl-trusted-publisher) for crates.io which is far from ideal, because it works completely against the idea to build trust for a single unified identity online, but ¯\(ツ)/¯.
But I always thought NPM was what the author describes - just a random set of packages with git sources, which I thought was the main issue (leftpad etc.). Isn't that the case?
What about one system that just works and is there for "ages": maven repository?
NPM doesn't require any version control, it's just a repository for files. The "main" issue (if one could be called such) around leftpad is that the types of ranges that could be specified for grabbing versions was very loose, and many dependencies of dependencies might just grab whatever is "latest".
Then, when someone throws a fit, they upload a broken version to NPM, and everyone downstream is SOL (or the package is given over to a malicious maintainer, or the maintainer is hacked, etc).
Heck, NPM doesn't (didn't?) require a license either. One of my former employers never let us use Webpack 1.x because it depended on something that depended on something that depended on a package from the very early days of NPM that didn't come with a license (it was by isaacs iirc, so it was meant to be public, but the version specified wasn't licensed). It wasn't until webpack 2.x that the versions were updated enough that all of the dependencies were formally open source.
I appreciate prople's efforts but they are misplaced. If I were passionate about this-- i'd do two things
1) A crates.io alternative which allows namespaces in package names like GitHub or alternatively. Single universal namespace doesn't seem fine (I don't think there would be necessarily changes required on the cargo side if users are willing to use full urls)
2) some kind of trust system so a user can up/down vote a package
3) Take a small one time payment for verifying a package? I don't know how this would work.
And in general, people pointing at Rust "limited" stdlib (it's only limited compared to Python) as one of the big issue and risk with rust are, in my opinion, misguided. You will never make an stdlib big enough to remove the need for external dependencies. It also creates a bunch of other problems. Actually, to take Python as an example, some functionality being in the stdlib have created a bunch of issue over the years since you can't just introduce breaking changes in an stdlib as easily. Look at urllib2/3 or xml in python. In the end, almost everyone ends up using requests and lxml instead. There are many issues that need to be dealt with to mitigate supply chain attacks. A bigger stdlib or an "stdlib-extended" a la Boost, is not one of them.
Also, specifically for Rust, many people run in a no-std environment (anything sized constraint for the most part). So another stdlib would do nothing for them.
Erm ....
Its limited compared to Go as well.
And that's a BIG deal because Go gives you single binaries with a stdlib that allows you to hit the ground running in a serious manner.
For example, making API calls which is the sort of thing many here do for their bread and butter. Everything you need to do can be don in Go stdlib without opening yourself up to supply chain vulnerabilities or having to choose which crate or having to keep track of crates versioning.
It feels like this is worse than a package manager? As in why would I trust a random git repo to keep things up to date over the officially published channel?
The other reason I don’t trust them is because this repo is 100% AI slop, even for crypto code. He posted it on /r/rust where every comment was highly negative - https://www.reddit.com/r/rust/s/4I4Xc7x7ec. The thread was removed by a moderator with the note:
Please, stop posting articles from kerkour.com.
The blog has been on a downward spiral for years, it's doomed, let it go.
So as I understand it, they're not suggesting that we pile many packages into 1 git repo as a sort of pseudo-crates.io, they're just promoting the fact that you can install a package directly from a git URL, rather than using a crate name on a registry.
What seems weird about that model to me is that dependancies will not sync between these individual packages. If package A chooses the canonical git URL for package C, and package B uses a self-hosted version of package C instead, you have two versions of package C.
(I’m more worried about judgement calls than implementation correctness, it’s not about AI.)
The big question about this project isn't its distribution, it's the core question it posed when it was first announced: are Rust developers going to seriously entertain an alternative "standard library" curated by one developer.
And the chances of a rogue actor or id theft reduce drastically.
It's quite an, ahem, interesting mix of libraries, including three csv libraries, hyper_utils (but not hyper itself), and a ton of copied crates from other maintainers.
I hope the author has a good way of updating these with upstream fixes (some look out-of-date already), otherwise you may replace one security issue with another.
And the name stdx has been taken on crates.io, more than 11 years ago which can also be equally confusing.
Oh is that true? They tied themselves to Microsoft it seems. What about people who won't or can't use GitHub.
Keep in mind that all of rustc and libs development takes place on Github.
What in my opinion is unacceptable is that it requires you to give permission to "read your organization and team membership and private Projects".
I made a separate GitHub account (weinzierl-trusted-publisher) for crates.io which is far from ideal, because it works completely against the idea to build trust for a single unified identity online, but ¯\(ツ)/¯.
Also Debian tries to build and distribute independently from crates.io.
So crates.io is important but is not the (Rust) world.
But I always thought NPM was what the author describes - just a random set of packages with git sources, which I thought was the main issue (leftpad etc.). Isn't that the case?
What about one system that just works and is there for "ages": maven repository?
Then, when someone throws a fit, they upload a broken version to NPM, and everyone downstream is SOL (or the package is given over to a malicious maintainer, or the maintainer is hacked, etc).
Heck, NPM doesn't (didn't?) require a license either. One of my former employers never let us use Webpack 1.x because it depended on something that depended on something that depended on a package from the very early days of NPM that didn't come with a license (it was by isaacs iirc, so it was meant to be public, but the version specified wasn't licensed). It wasn't until webpack 2.x that the versions were updated enough that all of the dependencies were formally open source.
I appreciate prople's efforts but they are misplaced. If I were passionate about this-- i'd do two things
1) A crates.io alternative which allows namespaces in package names like GitHub or alternatively. Single universal namespace doesn't seem fine (I don't think there would be necessarily changes required on the cargo side if users are willing to use full urls)
2) some kind of trust system so a user can up/down vote a package
3) Take a small one time payment for verifying a package? I don't know how this would work.
1. What problem does stdx actually solve?
2. Ok, it's a git dep, seems fine? Why is the choice to publish or not publish in crates.io a big deal either way?