Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why stdx is not on crates.io

kerkour.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Why stdx is not on crates.io

#51

Post by joshka »

testdelacc1 wrote: post #16
sheept wrote: post #14

Earlier quoted context omitted.

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 = " " }

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 w…

[flagged]

Re: Why stdx is not on crates.io

#52

Post by worik »

maeln wrote: post #22

"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…

> stealing some code

Strong words. Care to back them up?

Re: Why stdx is not on crates.io

#53

Post by vlovich123 »

tialaramex wrote: post #34
deeebug wrote: post #6

Earlier quoted context omitted.

Looks like it's that, plus vibe coding (in areas like crypto!) - https://kerkour.com/stdx

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.

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.

Re: Why stdx is not on crates.io

#54

Post by vlovich123 »

insanitybit wrote: post #49
NoboruWataya wrote: post #35

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 ex…

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....

Re: Why stdx is not on crates.io

#55

Post by worik »

cetra3 wrote: post #2

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?

> As in why would I trust a random git repo

It is one repo to trust, rather than hundreds

That is the reason

Re: Why stdx is not on crates.io

#56

Post by worik »

testdelacc1 wrote: post #16
sheept wrote: post #14

Earlier quoted context omitted.

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 = " " }

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 w…

> 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

Re: Why stdx is not on crates.io

#57

Post by worik »

tptacek wrote: post #19
cetra3 wrote: post #2

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?

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

Re: Why stdx is not on crates.io

#58

Post by worik »

jcgrillo wrote: post #12

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)

Re: Why stdx is not on crates.io

#59

Post by quacker »

sfdsfef3f3f wrote: post #45
ameliaquining wrote: post #40

Earlier quoted context omitted.

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 se…

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 riddl…

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.

Re: Why stdx is not on crates.io

#60

Post by jcgrillo »

worik wrote: post #58
jcgrillo wrote: post #12

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 co…

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.

Post reply on HN