From 136a5b8e10f8195dffd35e409fdc0a997025db61 Mon Sep 17 00:00:00 2001 From: Manish Goregaokar Date: Fri, 16 Oct 2020 10:16:45 -0700 Subject: [PATCH] Incorporate feedback from Carol From https://github.com/Manishearth/namespacing-rfc/issues/2#issuecomment-710101569 --- 0000-packages-as-optional-namespaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-packages-as-optional-namespaces.md b/0000-packages-as-optional-namespaces.md index c67efbf..1eacaa5 100644 --- a/0000-packages-as-optional-namespaces.md +++ b/0000-packages-as-optional-namespaces.md @@ -79,7 +79,7 @@ Not all existing projects can transition to using namespaces here. For example, This proposal does not prevent anyone from taking `foo-bar` after you publish `foo/bar`. Given that the Rust crate import syntax for `foo/bar` is `foo_bar`, same as `foo-bar`, it's totally possible for a user to accidentally type `foo-bar` in `Cargo.toml` instead of `foo/bar`, and pull in the wrong, squatted, crate. -We currently prevent `foo-bar` and `foo_bar` from existing at the same time. We _could_ do this here as well, but it would only go in one direction: if `foo/bar` exists `foo-bar`/`foo_bar` cannot be published, but not vice versa. This limits the "damage" to cases where someone pre-squats `foo-bar` before you publish `foo/bar`, and the damage can be mitigated by checking to see if such a clashing crate exists when publishing, if you actually care about this attack vector. There are some tradeoffs there that we would have to explore. +We currently prevent `foo-bar` and `foo_bar` from existing at the same time. We _could_ do this here as well, but it would only go in one direction: if `foo/bar` exists, neither `foo-bar` nor `foo_bar` will be allowed to be published. However, if `foo-bar` or `foo_bar` exist, we would choose to allow `foo/bar` to be published, because we don't want to limit the use of names within a crate namespace due to crates outside the namespace existing. This limits the "damage" to cases where someone pre-squats `foo-bar` before you publish `foo/bar`, and the damage can be mitigated by checking to see if such a clashing crate exists when publishing, if you actually care about this attack vector. There are some tradeoffs there that we would have to explore. One thing that could mitigate `foo/bar` mapping to the potentially ambiguous `foo_bar` is using something like `foo::crate::bar` or `~foo::bar` or `foo::/bar` in the import syntax.