3 ms·

I'm not talking about self-hosting, i'm just saying that most people will have their source already on some stable location (typically a hosted forge). I'm not

I'm not talking about self-hosting, i'm just saying that most people will have their source already on some stable location (typically a hosted forge). I'm not so sure why crates.io should be any different than the typical source host: i don't trust you, so i'll run my own thing, but now people have to trust me and we're back at square one. All in all your points are mostly valid (i don't fully understand all your arguments about versions as integrity should be handled by git) but again referring to my first message, they are best addressed by a community repository: these kind of guarantees can only be addressed by a trusted entity and there no reason on the world everybody writing rust should be trusting the same entity (with such a lightweight management). It can only fail in some ways.

estebank 3y ago
> All in all your points are mostly valid (i don't fully understand all your arguments about versions as integrity should be handled by git) If you depend on github.com/owner/foo@1.0.0, there's nothing stopping owner from force pushing to foo to override an existing version. The way it can be mitigated is if your dependency declaration contains a hash, so Cargo.toml files would be closer to foo = { url = "github.com/owner/foo", tag = "1.0.0", hash ="$HASH$" }. > there no reason on the world everybody writing rust should be trusting the same entity Note that you can today depend on git repos, local paths, or on alternative crate repositories. In practice the only people doing so are either applications (for the former) or large air-gaped organizations (for the later).
- lapinot 3y ago
  > Note that you can today depend on git repos [..] Yes! That's what i'm doing and my whole argumentation is that this should be the encouraged default. Because cargo is already well designed and crates.io (or any custom cargo registry) only brings marginal value to it. Let people organize their infrastructure as they wish, it shouldn't be the business of a language implementation or build system.

estebank 3y ago

> All in all your points are mostly valid (i don't fully understand all your arguments about versions as integrity should be handled by git) If you depend on github.com/owner/foo@1.0.0, there's nothing stopping owner from force pushing to foo to override an existing version. The way it can be mitigated is if your dependency declaration contains a hash, so Cargo.toml files would be closer to foo = { url = "github.com/owner/foo", tag = "1.0.0", hash ="$HASH$" }. > there no reason on the world everybody writing rust should be trusting the same entity Note that you can today depend on git repos, local paths, or on alternative crate repositories. In practice the only people doing so are either applications (for the former) or large air-gaped organizations (for the later).

lapinot 3y ago
> Note that you can today depend on git repos [..] Yes! That's what i'm doing and my whole argumentation is that this should be the encouraged default. Because cargo is already well designed and crates.io (or any custom cargo registry) only brings marginal value to it. Let people organize their infrastructure as they wish, it shouldn't be the business of a language implementation or build system.