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

61–70 of 71 posts

Re: Why stdx is not on crates.io

#61

Post by insanitybit »

vlovich123 wrote: post #54
insanitybit wrote: post #49

Earlier quoted context omitted.

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.

Re: Why stdx is not on crates.io

#62

Post by sshine »

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?

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

Re: Why stdx is not on crates.io

#63

Post by worik »

jcgrillo wrote: post #60
worik wrote: post #58

Earlier quoted context omitted.

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

> 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

Re: Why stdx is not on crates.io

#64

Post by vlovich123 »

insanitybit wrote: post #61
vlovich123 wrote: post #54

Earlier quoted context omitted.

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, un…

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.

Re: Why stdx is not on crates.io

#65

Post by quacker »

sheept wrote: post #14
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?

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

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

Re: Why stdx is not on crates.io

#66

Post by simonask »

worik wrote: post #55
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

The reason is invalid.

Re: Why stdx is not on crates.io

#67

Post by pjjpo »

traceroute66 wrote: post #31
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…

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

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.

Re: Why stdx is not on crates.io

#68

Post by insanitybit »

vlovich123 wrote: post #64
insanitybit wrote: post #61

Earlier quoted context omitted.

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, un…

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.

Re: Why stdx is not on crates.io

#69

Post by vlovich123 »

insanitybit wrote: post #68
vlovich123 wrote: post #64

Earlier quoted context omitted.

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

Right. I think the strongest is to tie the namespace into the language’s module system if possible like what cargo is trying to do. It depends on the language. DNS namespaces also work provided you add a key to guarantee a DNS takeover doesn’t take over the package namespace.

But the important point is to reserve support to add namespacing in the future even if you punt on it initially. Although I still argue as a security measure it’s better to support namespacing from the get go. Trust and authorship are valuable. There’s also all sorts of cryptographically strong ways to guarantee namespace owenrship that haven’t been explored (eg how tor can do vanity domain name creation)

Re: Why stdx is not on crates.io

#70

Post by insanitybit »

vlovich123 wrote: post #69
insanitybit wrote: post #68

Earlier quoted context omitted.

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

Right. I think the strongest is to tie the namespace into the language’s module system if possible like what cargo is trying to do. It depends on the language. DNS namespaces also work provided you add a key to guarantee a DNS takeover doesn’t take over the package namespace. But the important point is to reserve support to add namespacing in the future even if you punt on it initially. Although I still argue as a se…

My current thinking is that if there's Trusted Publishing then you can embed something from the OIDC claim into the namespace, like a github username, or whatever the subject would be. So that would give you `github.username` or, for some other OIDC provider, `.`.

DNS feels like it's asking a lot of maintainers idk, I'm very hesitant to do that one.

The rust proposal feels somewhat clean at least due to module names mapping cleanly, I think I kinda like that so far.

Post reply on HN