Could rust do with a alternative?
from to on 28 Oct 2023 20:03 +0000

To me, the two major problems are:

  1. no namespaces

Someone uploads “serde2”? that’s blocked forever. Someone uploads a typo version of a popular package? Too bad for you, learn how to type.

  1. the github connection

If you want to contribute to you’re bound to github. No gitlab, codeberg, gitee, sourcehut, etc.

Not sure if there are any other problems, but those two seem like the biggest things and #1 is AFAIK not something they ever want to change + it would be difficult to as one would need a migration strategy.

#rust on 28 Oct 2023 20:56 +0000 next

Eh, they could change #1 if they allow current non-namespaced packages but don’t allow new ones. That’s a pretty lazy migration strategy, but they could take it a step further and allow aliases (e.g. serde can be namespace/serde, and that’s set on the serde package).

But the bigger issue is that the devs don’t want to support namespaces.

#2 is the stronger argument imo. A package manager should not rely on a single external source. on 28 Oct 2023 21:22 +0000 next

Isn’t github used only as the auth provider? It is not using any git features, just leaning on the security guarantees of github. I don’t find this too alarming.

If you want, you can use git links when declaring dependencies in Cargo.toml. So alternative to is basically any git host already! on 28 Oct 2023 21:28 +0000 next

Isn’t github used only as the auth provider?

Still makes you bound to github. Can’t publish to without github.

just leaning on the security guarantees of github

What security guarantee does github have? I can create a new account right now with a random email, sign up for and type-squat a package.

If you want, you can use git links when declaring dependencies in Cargo.toml. So alternative to is basically any git host already!

Sure, but how do you discover the package? That’s the other function of a registry. Also, I could easily just add another package as a submodule, but that’s not the point. on 28 Oct 2023 22:27 +0000

I think the security guarantee is for the user and their credentials, not the community and trustworthiness of individuals. on 29 Oct 2023 01:54 +0000

Semver checks don’t work with straight git urls, since you can only link to an explicit branch or commit, not a version. on 29 Oct 2023 02:45 +0000

version can be passed with git actually. And it will need to match with the version set in Cargo.toml from the git source.

I wouldn’t call that an alternative to crate registries though (of which, is only one impl).

Also tangentially related, cargo-vendor is a thing. on 29 Oct 2023 11:51 +0000

Semver strings allows stuff like “version 2.5.x, but below 2.5.6”. Then cargo calculates the best solution for satisfying all dependency specifications from all packages using a single version (if possible).

Specifying a version in addition to the git branch doesn’t help there at all, because you still have to do it manually then. on 29 Oct 2023 13:46 +0000

Yes. That is in part why I mentioned that it’s not a real alternative, and mentioned cargo-vendor as a possible basis for a less manual serviceable solution.

Serviceable, but not necessarily good still. extremists would still be better off using an alternative crates registry*.

* That’s something that already exists btw. True extremists don’t have to wait for the HN leak-promised Good Stuff. on 28 Oct 2023 22:04 +0000 next

Apparently there’s an effort underway. I don’t have any more context than this:

I will say that I actually like the flat namespace, but don’t have a strong opinion on 28 Oct 2023 22:35 +0000 next

Interesting. Nice to know there are more people who agree and with the time to do something. Hopefully something will come of it. on 29 Oct 2023 08:58 +0000 next

I hope they don’t end up fragmenting the community or the ecosystem. on 29 Oct 2023 15:17 +0000

Why should I believe this?

I followed the link in echelon’s HN profile to their GitHub profile. It’s the same name, like you’d expect, but I had to check.

If they were a member of the Rust project, they’d have an entry in the rust-lang/team repository, and they don’t. The fact that they’ve written some code in the Rust language doesn’t automatically make them trustworthy, or give them information about what happens in closed council meetings. on 30 Oct 2023 00:30 +0000

You should believe it as much as you want. I don’t have any inside knowledge myself, I just remembered an HN comment that was relevant to this post and linked it. on 29 Oct 2023 01:24 +0000 next

there’s, never actually used it myself, but it calls itself an alternative to on 29 Oct 2023 01:55 +0000 next

That’s just for the web-based UI, not the database behind it. on 29 Oct 2023 02:14 +0000

ah ok, so i’m assuming it doesn’t fix either of the issues listed then. thanks. on 29 Oct 2023 08:27 +0000

Not sure how that’s an alternative as there’s no way to add anything to it. It seems more like an aggregator that a registry. on 29 Oct 2023 04:49 +0000 next

While I don’t want to deny the problems of not having namespaces, they will introduce a new set of problems. One issue with Github and similar platforms with namespaces is that a search for a repo turns up multiple projects with the same name under different namespaces. It’s always a confusion as to which one is canonical. Another problem is that people are now going to name squat namespaces instead of project names. Imagine somebody registers the serde namespace. Their crates may be mistaken as the canonical one. on 29 Oct 2023 07:18 +0000 next

I know a lot of people want namespaces. And I think it would be nice for a bigger project to have an obvious way to show which packages are part of this big project, and which are not. For example the different serde serialization formats would not need to be listed in the docs, but simply be present in one single serde-formats namespaces.

It it does fuck all for type squatting. Sure, now I’m safe from getting malicious code by doing tokio/tokiu-http, but tokiu/tokio-http can still be malicious!

The only solution to type squatting would be a checksum. So instead of adding Tokio to your toml file you’d have to add e.g. tokio-fld, with the fld part being some kind of check that is derived from the name. Similar to a hash, all names that are similar to tokio would get a wildly different suffix. on 29 Oct 2023 08:23 +0000 next

It it does fuck all for type squatting. Sure, now I’m safe from getting malicious code by doing tokio/tokiu-http, but tokiu/tokio-http can still be malicious!

You are indeed correct. I hadn’t considered that!

The checksum idea might work 🤔 That definitely could be possible with the new registry. on 29 Oct 2023 19:56 +0000

I think you could get it with a signature, just like with Linux repos. Basically, the org would sign the metadata so you know it came from that org’s key.

That way you’d need both a malicious name and access to the key. You don’t need the suffix here, just a section in the toml that lets you list keys per org, and if it changes, you’d get prompted to update it. on 01 Nov 2023 17:43 +0000

I don’t think changing is the problem, incorrect initial entry is the problem. Linux has centralized package maintainers, cargo does not (or am I wrong?)

Or do you mean that adding a namespace would require a key and then all crates in that namespace are unlocked? Then only the initial cargo add would be dangerous, all subsequent ones in the same namespace would not require manual confirmation. on 01 Nov 2023 22:22 +0000

Yes, I’m saying that adding a namespace would require a key, and all releases would be signed with that key. That works similarly to installing a separate repo in a Linux distro, you’d import the key and mark it as trusted, and then signatures would be verified for each download.

So yes, only the initial cargo add would be “dangerous,” and there would be a prompt for the user to verify that they have the right key (which they could verify on the project homepage). on 29 Oct 2023 08:36 +0000 next

If Github isn’t used for source control, why on earth is it the only auth provider?

Why has given Microsoft the ability to control who can and cannot publish Rust code?

Namespacing is whatever, but IMO the real issue is the disproportionate and unnecessary amount of power given to a company known for pushing monopolies. on 29 Oct 2023 13:29 +0000

  • GitHub wasn’t always owned by Microsoft. At least get your dates right.
  • Yes, GH shouldn’t be the sole auth provider. on 29 Oct 2023 19:19 +0000 next

For #2, there isn’t anything stopping a separate auth system not through GitHub. Really just needs someone to own the implementation. See… for past discussion surrounding this. on 30 Oct 2023 09:25 +0000

I don’t understand the “serde2” issue. Isn’t “someusername/serde” strictly worse than “serde2”?

GitHub being the only auth provider is something the maintainers wanted to fix, but didn’t have enough bandwidth to implement. I think they would welcome contributions!