"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.
Take for example https://github.com/rust-stdx/stdx/tree/main/itoa. Its licenses and copyright information have been stripped. You are permitted to make copies of code under the MIT license, but the license also includes:
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
If the original repo were to disappear, it would be important to know who wrote the code and what the license actually is.
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. The same could be said of crypto or hundreds of other things present in the Go stdlib.
It depends on perspective. Go is tailored for writing backends, so it's great that it provides things like net/http (we could also interpret cause and effect inversely here; Go provides net/http so it gets used for writing backends). Rust's standard library is actually pretty damn huge, but it doesn't index heavily into specific applications, and instead tries to provide comprehensive support for low-level operations that enable you to build a custom-tailored solution to whatever you need on top of it. Rust's stdlib is "small" if all you want to do is build a webserver and don't want to go shopping around for libraries, but anyone who's intimately familiar with Rust's stdlib can tell you for a fact that it's absolutely not small in absolute terms. Rust literally stabilizes hundreds of new stdlib functions per year.
> and instead tries to provide comprehensive support for low-level operations that enable you to build a custom-tailored solution to whatever you need on top of it
So in other words Rust forces you to either (a) re-invent the wheel (yet again !) or (b) import yet-another-crate into your project.
Of course if you choose (b), then its having first wasted your time deciding which of hundreds of yet-another-crate-doing-the-same-thing you want to import.
Its a waste of time and effort for the majority of projects where you are not working with embedded systems or trying to squeeze every micro-second of performance out of your system.
Sadly the majority of Rust projects show exactly zero import discipline, both from a pure import perspective and a security perspective. Which is why many Rust projects end up importing a gazillion crates.
Import discipline in Rust is hard work. Sure you can reach "reasonably necessary" level of imports the majority of Rust projects simply don't bother because its such a pain in the backside.
Don't get me wrong, Rust has its place in this world. But for many people on many projects they would be better off using Go and only using Rust where there is actually a serious use-case for it in their environment.
> Rust forces you to either (a) re-invent the wheel (yet again !)
This is inherent to the domain of systems programming. One-size-fits-all solutions only suffice until you need extreme performance. So, for example, Rust provides a basic hashmap in the stdlib, and as a generalist hashmap it's quite close to state-of-the-art. But as a generalist hashmap it's also beaten in specific applications by specialist datastructures, and Rust needs to provide support for building those specialist datastructures in a way that makes them feel just as first-class as what the stdlib provides.
Go gets away with what it does because it's for domains where it's acceptable to trade uniformity for performance. This is not a bad thing! Go is quite performant. But Rust ultimately isn't competing with Go, it's competing with C.
And note that I say all this as someone who is, in fact, a stdlib maximalist. But I also say all this as someone who is conscientious and informed of the realities of what it takes to design and maintain a secure, high-performance stdlib.
Yeah, not long ago on HN I read into somebody who really wanted a type that's a list of blocks which expands and shrinks only by whole blocks. Such a type would have amortized O(1) push at one end, like Vec, and also amortized O(1) pop - but with much smaller and more frequent allocations, and the index access is horrible, but it would only ever be over-allocating by a bounded amount, this is a relatively inconvenient type for a lot of purposes which is why AFAIK nobody provides this out of the box, but it did suit their needs.
Lest people imagine Rust has so few collections because nobody offered any others, Aria has a rant in her Linked Lists "tutorial" where she explains that pre Rust 1.0 she was cleaning out all the miscellaneous collection types few people need - and she tried but failed to remove the linked list type. There's some very niche types in her list, things I've heard of but never used in decades of professional software engineering.
This is mostly only true if you're writing a network service or maybe a CLI tool. Which is fair enough, since that's what Go is primarily for, but Rust aims to be, not just usable, but the best option, in a broader variety of domains. It wouldn't be feasible to have a batteries-included stdlib for all of them. (Python historically tried, and the results have been rather famously unsatisfactory.)
Also, even network services benefit from things like OpenAPI for type safety, and you don't get that from the Go stdlib.
> even network services benefit from things like OpenAPI for type safety, and you don't get that from the Go stdlib.
Sure, but the point is for the majority of people writing stuff in Go, they can get 99% of the way there with the Go stdlib.
Then, if they need to import one or two things to help them, such as the AWS Go SDK or whatever, that's perfectly fine.
It still means you end up with a go.mod file that has literally only two or three third-party imports in it.
Meanwhile if you wanted to write the equivalent tool in Rust, if you don't care you'll quickly end up with a Cargo.toml measured in hundreds of lines.
And if you are willing to put in the hours to hand-cherry-pick and make your Rust imports "reasonably necessary", then you'll still have a whole bunch more third-party imports than the Go equivalent.
A huge portion of the Go standard library is extremely low quality as well. flag, container, image, json, log, much of math, path, regexp, sync and time are all notoriously low quality and will almost certainly get improved versions similar to encoding/json/v2. The container package alone has to be the worst package included with any major programming language in history. The standard library in general is also riddled with abstractions that don't hold across the various platforms that they claim to support. path and os are particularly awful in this regard.
Also if you go look at any real Go projects they usually use tons of dependencies and they're usually pinned to random git hashes which is its own massive problem.
if you go look at any real Go projects they usually use tons of dependencies and they're usually pinned to random git hashes
No, they are usually pinned to a git tag, which is usually a version string representing a released version. And the tag is locked to a hash to detect if the tag is later modified.
I don't know of anyone accessing a database like Postgres with just the stdlib in real apps. Or maybe the API is just serving data out of a JSON file checked in the repo?
I agree the stdlib is great but the reality is production apps cannot be built using only it.
Most codebases have dependencies. Most accept dependency updates from renovate etc without much thought. Go can remain secure if goproxy has thorough security scans (I think they do but am not sure if it's unbeatable) and if the fact that any attack will be in OSS code itself, rather than packaged just-in-time in a workflow, makes it visible before significant damage. I have no idea if the latter is true but it might be. Of course NPM packages are just as visible as long as someone is scanning them so maybe not.
> 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.
And yet, I've been in situations where the only thing I had was urllib2, and I was very grateful it existed. It's awesome that the Python stdlib has everything it does, even if most of the time a pypi package is going to be superior.
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?
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 whole "There are test vectors so we know it's correct" is a strong sign that this isn't actually safe to use and that indeed the people who built it (to the extent people actually did build it) have no idea what they're doing.
To save you a read of the original while still having enough context, here's the whole section on crypto:
> crypto: spec and test-driven development to the rescue
> Cryptographic code is famously hard, with many, many footguns haunting unsuspecting developers (and even experts!).
> But, cryptography also has something that you likely won't find in any other domain: an extensive public collection of test vectors, particularly for edge cases. Every algorithm specification come with a basic suite of test vectors, but there are also community-built wonders such as Wycheproof.
> These test vectors, combined with the official specification documents of the crypto algorithms were rather effective to guide the coding agents and avoid the worst hallucinations.
> Cost: ~ $30
> Time: multiple days of part-time work.
> I'm under no illusion that the crypto crate is currently bug-free, but if my experience told me anything, it's that even experienced programmers are shipping bugs in crypto libraries. So, for similar outcomes, but using 1/100 of the time and at maybe 1/1000 of the cost, I think it's a clear demonstratin of AI's effectiveness.
For anyone wondering why, test vectors only cover “did the encryption work”. It does not cover “did you maintain constant time guarantees” to prevent against side channel attacks as an example. Crypto is filled with all kinds of such pitfalls that aren’t covered by conformance tests.
Hence “strong sign this is built by people who have no idea what they’re doing” is accurate.
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.
> The blog has been on a downward spiral for years, it's doomed, let it go.
Argumentum ad hominem, yuk
> the fundamental mistake of assuming that they’re trustworthy and we’d trust them no questions asked.
The author makes no such assumption, it is entirely your decision
> this repo is 100% AI slop,
That is an exaggeration. It is coded with AI help, as is almost everything these days
Agree, or disagree, that an anemic standard library is a problem, and crates.io is a glaring security risk and a looming catastrophe Kerkour is doing something about it
AFAIK, Golang's module system (mentioned in the article) protects against this. From [1],
The revision must be an ancestor of one of the module repository’s branches or tags. This prevents attackers from referring to unapproved changes or pull requests.
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.
Namespace pollution is an annoying problem in Rust. A while ago I was looking for a crate to help build something to interact with Apache Solr. Great, there's a Rust crate called `solr` on crates.io. And here it is: https://github.com/lambdastackio/solr-rust
There are other examples of crates registered on crates.io with prominent names that are just stubs with one commit from years ago. I'm sure this problem also exists for other languages but it feels worse with Rust, I suspect because of how easy it is to register a crate on crates.io combined with the "rewrite X in Rust" craze.
How do namespaces help? I'm building a package registry and I've decided against namespacing because I can not see how to implement it in a way that doesn't just lead to even worse problems.
Because @apache/solr would be easier to disambiguate vs @randomuser/solr.
You should really build namespaces in from the start, or at least reserve the capability to do so in the future. Unless you want to speed run all the lessons already learned.
What stops someone from just squatting the namespace? What is the concrete value? Who gets a namespace? Who gets "apache"'s namespace? Is it a problem if a user takes "apache" or "anthropic"? Do you use domain registration to determine who owns a namespace?
I'll read the article soon fwiw, but those questions come to mind. I'm definitely open to it.
For now I have:
1. Minimum "typo distance" between package names, unless within the same author.
2. Trusted Publishing + 2FA to promote from "published" to "released" required, no API keys.
3. 1 day dependency cooldown by default.
4. The language (and the build system, built in the language) has explicit capabilities model so you can statically verify what build scripts are allowed to do.
I feel like the benefit of namespacing must be quite low at this point but perhaps I need to reevaluate.
If you can’t be bothered to read the paper that covers all of it, why should I be bothered to respond? Do whatever you want, I’m just highlighting this space is well studied and you’re insisting on retreading ground where the consequences are well-studied.
As I said, I will read it (in fact, right now!). Perfectly reasonable to say "that's all addressed in the post", of course.
edit: I'll have to reread it perhaps. I feel like the article largely motivates my points about how complex namespace registration is and how it just punts the problem (or adds new problems like "you hijacked the entire namespace"). It doesn't seem like there's a strong proposal in the article other than to make namespaces support built-in by default to make later migrations easier if a solution does come about, which is reasonable and something I can do.
I'll read the linked PEP/RFCs to learn more about how others are solving this but I think my opinion is still mostly that registries trade some problems for other (worse?) problems.
At minimum it seems notable to restrict package names in general as it allows more options for denotation in the future.
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 ¯\(ツ)/¯.
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.
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.
Ok, I was curious enough to read look into this, but it makes no sense under the hood. The idea is essentially that:
1. Supply-chain problems affect the Rust ecosystem arguably even worse than npm.
2. `stdx` extends Rust by adding some other stuff in Go that's good for supply-chain security?
3. crates.io does stuff differently than stdx so that's why it's distributed exclusively via git.
But none of the README or article linked by the author or the other article linked in the README explain anything about what the good things from Go are that are actually added, or what the pain point precisely is compared to using crates.io. I think the first proposition is possibly correct, mainly because I know next to nothing about Rust but am all too familiar with supply-chain complaints (as are most of us by now) whether as to npm or Python ecosystems, and there is no principled reason why Rust should be more secure unless the fundamental assumption of trusting external packages to auto-update safely is somehow different in Rust. I assume without loss of generality that perhaps the author is right that Rust's package management ecosystem is no more secure as a supply-chain than Node.js's ecosystem. The second property also might be true too that Go offers some concrete solutions to the problem, though I have no idea if that's correct and wouldn't necessarily assume that to be true.
Still, even assuming all claims to be true, I do not see is any connection between those claims and actual implementation of code, aside from talk about how stdx is AI-friendly and was generated using AI. I just don't get what this does that is any different. You're still trusting a Git repository to be valid. In fact it almost sounds at one point like the author is suggesting that the whole exercise of providing proof of provenance and demonstrating that a particular version was properly published by its author is too tedious and annoying and should therefore be skipped by utilizing a simpler stdx approach to Rust (but I still don't know what that is or why I should trust it!). Is it just me? This makes no sense.
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.
Conceptually that makes sense, but has there been a supply chain problem lately? It's been a few years since I worked on a large rust project with tons of deps, but I don't recall there being a big problem. Especially with cargo vendor.
If fully auditing a collection of deps is the goal, it seems that could be accomplished by maintaining a list of repos and trusted commit hashes?
I guess I'm wondering whether there's some incremental solution that fits better with how the rest of the ecosystem works?
EDIT: just saw reference to cargo-vet, very cool! Thanks Colin.
"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.
How is code being "stolen" here? It's FOSS code that is being copied.
Take for example https://github.com/rust-stdx/stdx/tree/main/itoa. Its licenses and copyright information have been stripped. You are permitted to make copies of code under the MIT license, but the license also includes:
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
If the original repo were to disappear, it would be important to know who wrote the code and what the license actually is.
Oh wow you are right, thats really bad. Terrible look for the author.
> it's only limited compared to Python
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. The same could be said of crypto or hundreds of other things present in the Go stdlib.
> Its limited compared to Go as well.
It depends on perspective. Go is tailored for writing backends, so it's great that it provides things like net/http (we could also interpret cause and effect inversely here; Go provides net/http so it gets used for writing backends). Rust's standard library is actually pretty damn huge, but it doesn't index heavily into specific applications, and instead tries to provide comprehensive support for low-level operations that enable you to build a custom-tailored solution to whatever you need on top of it. Rust's stdlib is "small" if all you want to do is build a webserver and don't want to go shopping around for libraries, but anyone who's intimately familiar with Rust's stdlib can tell you for a fact that it's absolutely not small in absolute terms. Rust literally stabilizes hundreds of new stdlib functions per year.
> and instead tries to provide comprehensive support for low-level operations that enable you to build a custom-tailored solution to whatever you need on top of it
So in other words Rust forces you to either (a) re-invent the wheel (yet again !) or (b) import yet-another-crate into your project.
Of course if you choose (b), then its having first wasted your time deciding which of hundreds of yet-another-crate-doing-the-same-thing you want to import.
Its a waste of time and effort for the majority of projects where you are not working with embedded systems or trying to squeeze every micro-second of performance out of your system.
Sadly the majority of Rust projects show exactly zero import discipline, both from a pure import perspective and a security perspective. Which is why many Rust projects end up importing a gazillion crates.
Import discipline in Rust is hard work. Sure you can reach "reasonably necessary" level of imports the majority of Rust projects simply don't bother because its such a pain in the backside.
Don't get me wrong, Rust has its place in this world. But for many people on many projects they would be better off using Go and only using Rust where there is actually a serious use-case for it in their environment.
> Rust forces you to either (a) re-invent the wheel (yet again !)
This is inherent to the domain of systems programming. One-size-fits-all solutions only suffice until you need extreme performance. So, for example, Rust provides a basic hashmap in the stdlib, and as a generalist hashmap it's quite close to state-of-the-art. But as a generalist hashmap it's also beaten in specific applications by specialist datastructures, and Rust needs to provide support for building those specialist datastructures in a way that makes them feel just as first-class as what the stdlib provides.
Go gets away with what it does because it's for domains where it's acceptable to trade uniformity for performance. This is not a bad thing! Go is quite performant. But Rust ultimately isn't competing with Go, it's competing with C.
And note that I say all this as someone who is, in fact, a stdlib maximalist. But I also say all this as someone who is conscientious and informed of the realities of what it takes to design and maintain a secure, high-performance stdlib.
Yeah, not long ago on HN I read into somebody who really wanted a type that's a list of blocks which expands and shrinks only by whole blocks. Such a type would have amortized O(1) push at one end, like Vec, and also amortized O(1) pop - but with much smaller and more frequent allocations, and the index access is horrible, but it would only ever be over-allocating by a bounded amount, this is a relatively inconvenient type for a lot of purposes which is why AFAIK nobody provides this out of the box, but it did suit their needs.
Lest people imagine Rust has so few collections because nobody offered any others, Aria has a rant in her Linked Lists "tutorial" where she explains that pre Rust 1.0 she was cleaning out all the miscellaneous collection types few people need - and she tried but failed to remove the linked list type. There's some very niche types in her list, things I've heard of but never used in decades of professional software engineering.
This is mostly only true if you're writing a network service or maybe a CLI tool. Which is fair enough, since that's what Go is primarily for, but Rust aims to be, not just usable, but the best option, in a broader variety of domains. It wouldn't be feasible to have a batteries-included stdlib for all of them. (Python historically tried, and the results have been rather famously unsatisfactory.)
Also, even network services benefit from things like OpenAPI for type safety, and you don't get that from the Go stdlib.
> even network services benefit from things like OpenAPI for type safety, and you don't get that from the Go stdlib.
Sure, but the point is for the majority of people writing stuff in Go, they can get 99% of the way there with the Go stdlib.
Then, if they need to import one or two things to help them, such as the AWS Go SDK or whatever, that's perfectly fine.
It still means you end up with a go.mod file that has literally only two or three third-party imports in it.
Meanwhile if you wanted to write the equivalent tool in Rust, if you don't care you'll quickly end up with a Cargo.toml measured in hundreds of lines.
And if you are willing to put in the hours to hand-cherry-pick and make your Rust imports "reasonably necessary", then you'll still have a whole bunch more third-party imports than the Go equivalent.
A huge portion of the Go standard library is extremely low quality as well. flag, container, image, json, log, much of math, path, regexp, sync and time are all notoriously low quality and will almost certainly get improved versions similar to encoding/json/v2. The container package alone has to be the worst package included with any major programming language in history. The standard library in general is also riddled with abstractions that don't hold across the various platforms that they claim to support. path and os are particularly awful in this regard.
Also if you go look at any real Go projects they usually use tons of dependencies and they're usually pinned to random git hashes which is its own massive problem.
if you go look at any real Go projects they usually use tons of dependencies and they're usually pinned to random git hashes
No, they are usually pinned to a git tag, which is usually a version string representing a released version. And the tag is locked to a hash to detect if the tag is later modified.
Rust gives you statically linked binaries as well.
So your argument boils down to having to add `reqwest = "0.13.3"` to your `Cargo.toml`.
I don't know of anyone accessing a database like Postgres with just the stdlib in real apps. Or maybe the API is just serving data out of a JSON file checked in the repo?
I agree the stdlib is great but the reality is production apps cannot be built using only it.
Most codebases have dependencies. Most accept dependency updates from renovate etc without much thought. Go can remain secure if goproxy has thorough security scans (I think they do but am not sure if it's unbeatable) and if the fact that any attack will be in OSS code itself, rather than packaged just-in-time in a workflow, makes it visible before significant damage. I have no idea if the latter is true but it might be. Of course NPM packages are just as visible as long as someone is scanning them so maybe not.
> 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.
And yet, I've been in situations where the only thing I had was urllib2, and I was very grateful it existed. It's awesome that the Python stdlib has everything it does, even if most of the time a pypi package is going to be superior.
> stealing some code
Strong words. Care to back them up?
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?
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.
Looks like it's that, plus vibe coding (in areas like crypto!) - https://kerkour.com/stdx
Uh, yeah, this is not the writing of someone with the experience to maintain a cryptography toolkit: https://kerkour.com/nist-cryptography-backdoor
(I’m more worried about judgement calls than implementation correctness, it’s not about AI.)
Hah, length-extension and CBC mode, famous NIST backdoors.
The whole "There are test vectors so we know it's correct" is a strong sign that this isn't actually safe to use and that indeed the people who built it (to the extent people actually did build it) have no idea what they're doing.
To save you a read of the original while still having enough context, here's the whole section on crypto:
> crypto: spec and test-driven development to the rescue
> Cryptographic code is famously hard, with many, many footguns haunting unsuspecting developers (and even experts!).
> But, cryptography also has something that you likely won't find in any other domain: an extensive public collection of test vectors, particularly for edge cases. Every algorithm specification come with a basic suite of test vectors, but there are also community-built wonders such as Wycheproof.
> These test vectors, combined with the official specification documents of the crypto algorithms were rather effective to guide the coding agents and avoid the worst hallucinations.
> Cost: ~ $30
> Time: multiple days of part-time work.
> I'm under no illusion that the crypto crate is currently bug-free, but if my experience told me anything, it's that even experienced programmers are shipping bugs in crypto libraries. So, for similar outcomes, but using 1/100 of the time and at maybe 1/1000 of the cost, I think it's a clear demonstratin of AI's effectiveness.
Yeah, terrifyingly clueless, don't use.
For anyone wondering why, test vectors only cover “did the encryption work”. It does not cover “did you maintain constant time guarantees” to prevent against side channel attacks as an example. Crypto is filled with all kinds of such pitfalls that aren’t covered by conformance tests.
Hence “strong sign this is built by people who have no idea what they’re doing” is accurate.
One upside I can think is that it is easier to trust and verify one repo than hundreds.
And the chances of a rogue actor or id theft reduce drastically.
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:
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.
> The blog has been on a downward spiral for years, it's doomed, let it go.
Argumentum ad hominem, yuk
> the fundamental mistake of assuming that they’re trustworthy and we’d trust them no questions asked.
The author makes no such assumption, it is entirely your decision
> this repo is 100% AI slop,
That is an exaggeration. It is coded with AI help, as is almost everything these days
Agree, or disagree, that an anemic standard library is a problem, and crates.io is a glaring security risk and a looming catastrophe Kerkour is doing something about it
This is a start
This is hugely problematic behavior of github
AFAIK, Golang's module system (mentioned in the article) protects against this. From [1],
The revision must be an ancestor of one of the module repository’s branches or tags. This prevents attackers from referring to unapproved changes or pull requests.
1: https://go.dev/ref/mod
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.
I am a supporter of Kerkour's efforts
> are Rust developers going to seriously entertain an alternative "standard library" curated by one developer.
No. Absolutely not
But this is a start. Join the effort. Help them
> As in why would I trust a random git repo
It is one repo to trust, rather than hundreds
That is the reason
The reason is invalid.
> stdx is a monorepo of, as of today, 64 crates
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.
Sounds to me stdx is doing this wrong more than anything else.
Ignore this and just use `cargo-vet`, you're welcome.
Namespace pollution is an annoying problem in Rust. A while ago I was looking for a crate to help build something to interact with Apache Solr. Great, there's a Rust crate called `solr` on crates.io. And here it is: https://github.com/lambdastackio/solr-rust
There are other examples of crates registered on crates.io with prominent names that are just stubs with one commit from years ago. I'm sure this problem also exists for other languages but it feels worse with Rust, I suspect because of how easy it is to register a crate on crates.io combined with the "rewrite X in Rust" craze.
If you sort by recent downloads, you find that https://crates.io/crates/solrstice looks likely most popular
How do namespaces help? I'm building a package registry and I've decided against namespacing because I can not see how to implement it in a way that doesn't just lead to even worse problems.
Because @apache/solr would be easier to disambiguate vs @randomuser/solr.
You should really build namespaces in from the start, or at least reserve the capability to do so in the future. Unless you want to speed run all the lessons already learned.
https://nesbitt.io/2026/02/14/package-management-namespaces....
What stops someone from just squatting the namespace? What is the concrete value? Who gets a namespace? Who gets "apache"'s namespace? Is it a problem if a user takes "apache" or "anthropic"? Do you use domain registration to determine who owns a namespace?
I'll read the article soon fwiw, but those questions come to mind. I'm definitely open to it.
For now I have:
1. Minimum "typo distance" between package names, unless within the same author.
2. Trusted Publishing + 2FA to promote from "published" to "released" required, no API keys.
3. 1 day dependency cooldown by default.
4. The language (and the build system, built in the language) has explicit capabilities model so you can statically verify what build scripts are allowed to do.
I feel like the benefit of namespacing must be quite low at this point but perhaps I need to reevaluate.
If you can’t be bothered to read the paper that covers all of it, why should I be bothered to respond? Do whatever you want, I’m just highlighting this space is well studied and you’re insisting on retreading ground where the consequences are well-studied.
As I said, I will read it (in fact, right now!). Perfectly reasonable to say "that's all addressed in the post", of course.
edit: I'll have to reread it perhaps. I feel like the article largely motivates my points about how complex namespace registration is and how it just punts the problem (or adds new problems like "you hijacked the entire namespace"). It doesn't seem like there's a strong proposal in the article other than to make namespaces support built-in by default to make later migrations easier if a solution does come about, which is reasonable and something I can do.
I'll read the linked PEP/RFCs to learn more about how others are solving this but I think my opinion is still mostly that registries trade some problems for other (worse?) problems.
At minimum it seems notable to restrict package names in general as it allows more options for denotation in the future.
> Also, you can only create a crates.io account with a GitHub account
Oh is that true? They tied themselves to Microsoft it seems. What about people who won't or can't use 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 ¯\(ツ)/¯.
Multiple free accounts are also against GitHub TOS
A clause that I think should be illegal, btw
I pay for my main account, but good point.
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.
There is some recent progress on https://github.com/rust-lang/crates.io/issues/326
I'm a bit new to rust or npm system.
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.
Ok, I was curious enough to read look into this, but it makes no sense under the hood. The idea is essentially that:
1. Supply-chain problems affect the Rust ecosystem arguably even worse than npm. 2. `stdx` extends Rust by adding some other stuff in Go that's good for supply-chain security? 3. crates.io does stuff differently than stdx so that's why it's distributed exclusively via git.
But none of the README or article linked by the author or the other article linked in the README explain anything about what the good things from Go are that are actually added, or what the pain point precisely is compared to using crates.io. I think the first proposition is possibly correct, mainly because I know next to nothing about Rust but am all too familiar with supply-chain complaints (as are most of us by now) whether as to npm or Python ecosystems, and there is no principled reason why Rust should be more secure unless the fundamental assumption of trusting external packages to auto-update safely is somehow different in Rust. I assume without loss of generality that perhaps the author is right that Rust's package management ecosystem is no more secure as a supply-chain than Node.js's ecosystem. The second property also might be true too that Go offers some concrete solutions to the problem, though I have no idea if that's correct and wouldn't necessarily assume that to be true.
Still, even assuming all claims to be true, I do not see is any connection between those claims and actual implementation of code, aside from talk about how stdx is AI-friendly and was generated using AI. I just don't get what this does that is any different. You're still trusting a Git repository to be valid. In fact it almost sounds at one point like the author is suggesting that the whole exercise of providing proof of provenance and demonstrating that a particular version was properly published by its author is too tedious and annoying and should therefore be skipped by utilizing a simpler stdx approach to Rust (but I still don't know what that is or why I should trust it!). Is it just me? This makes no sense.
stdx is on crates.io: https://crates.io/crates/stdx
But it seems to be a placeholder crate of sorts and is not Kerkour's stdx.
It does re-export several other crates, but has not been maintained or updated in a long time.
stdx is not the best example. The most popular package that is not on crates.io is probably embassy.
Also Debian tries to build and distribute independently from crates.io.
So crates.io is important but is not the (Rust) world.
There's no single "embassy" crate, but all the components (HALs, executor, usb, net, etc.) are all on crates io and have been for a long time.
Oh, good to know, thanks!
More like which stdx?
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.
going where the people aren’t, a well understood strategy
I don't get it, maybe my brain isn't wrinkly enough. Two things:
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?
> What problem does stdx actually solve?
Even a small rust programme can end up importing hundreds of crates. For many applications you need to investigate and verify your dependencies.
A substantialstandard library, the hypothesis is, will vastly reduce the number of sources you need to trust
It is early days for this, it is not to be trusted yet.
2. It is not crates.io specifically that is the problem. It is the concept of using many imports that all need verifying (my original statement here)
Conceptually that makes sense, but has there been a supply chain problem lately? It's been a few years since I worked on a large rust project with tons of deps, but I don't recall there being a big problem. Especially with cargo vendor.
If fully auditing a collection of deps is the goal, it seems that could be accomplished by maintaining a list of repos and trusted commit hashes?
I guess I'm wondering whether there's some incremental solution that fits better with how the rest of the ecosystem works?
EDIT: just saw reference to cargo-vet, very cool! Thanks Colin.
> It's been a few years since I worked on a large rust project with tons of deps, but I don't recall there being a big problem.
The problem was ignored, perhaps?
Not every project is vulnerable, but many systems programming tasks are
I have encounted it
> Why is the choice to publish or not publish in crates.io a big deal either way?
The aspiration is to distribute stdx in a way similar to libc and never rely on crates.io, bypassing supply-chain problems altogether.