I agree partly. I love cargo and can’t understand why certain things like package namespaces and proof of ownership isn’t added at a minimum. I was mega annoyed when I had to move all our Java packages from jcenter, which was a mega easy setup and forget affair, to maven central. There I suddenly needed to register a group name (namespace mostly reverse domain) and proof that with a DNS entry. Then all packages have to be signed etc. In the end it was for this time way ahead. I know that these measures won’t help for all cases. But the fact that at least on npm it was possible that someone else grabs a package ID after an author pulled its packages is kind of alarming. Dependency confusion attacks are still possible on cargo because the whole - vs _ as delimiter wasn’t settled in the beginning. But I don’t want to go away from package managers or easy to use/sharable packages either.

▲

kibwen 6 hours ago | parent [-]

> But the fact that at least on npm it was possible that someone else grabs a package ID after an author pulled its packages is kind of alarming.

Since your comment starts with commentary on crates.io, I'll note that this has never been possible crates.io.

> Dependency confusion attacks are still possible on cargo because the whole - vs _ as delimiter wasn’t settled in the beginning.

I don't think this has ever been true. AFAIK crates.io has always prevented registering two different crates whose names differ only in the use of dashes vs underscores.

> package namespaces

See https://github.com/rust-lang/rust/issues/122349

> proof of ownership

See https://github.com/rust-lang/rfcs/pull/3724 and https://blog.rust-lang.org/2025/07/11/crates-io-development-...

▲

larusso 3 hours ago | parent | next [-]

You are right. I remembered it wrong.

https://rust-lang.github.io/rfcs/0940-hyphens-considered-har...

Was from 2015 and the other discussions I remember were around default style and that cargo already blocks a crate when normalized name is equal.

▲

larusso 3 hours ago | parent | prev [-]

The trusted publishing is rather new or? Awesome to see that they implemented it. Just saying that maven central required it already years ago.

▲

di 2 hours ago | parent [-]

Maven Central does not currently support OIDC-based authentication (commonly called "Trusted Publishing").

	▲	larusso an hour ago \| parent [-]
		Didn’t know this term. After reading I wonder why short lived tokens get this monocle. But yeah I prefer OIDC over token based access as well. Only small downside I see is the setup needed for a custom OIDC provider. Don’t know the right terms out of my head but we had quite the fun to register our internal Jenkins to become a create valid oidc tokens for AWS. GitHub and GitHub Actions come with batteries included. I mean the downside that a huge vendor can easily provide this and a custom rolled CI needs extra steps / infrastructure.