6 ms·

If a package transfer does need to occur, then the only method to do so should be the owner doing it. The registry itself shouldn't have the ability. This migh

by l0b0 5y ago

If a package transfer does need to occur, then the only method to do so should be the owner doing it. The registry itself shouldn't have the ability. This might be fighting fire with napalm. Namesquatting is very much a thing, and if every new package registry finds itself with millions of common names registered on day 1 those registries are going to become a lot less useful. This is also going to encourage a lot of bottom feeders to get money just to go away. Package registries should instead consider all parties' (including greedy and unscrupulous third parties) motives, and try to come up with some scheme to make sure this process works.

Jtsummers 5y ago
Shallow, unqualified naming is part of the issue here. Look up, for instance, anything with the "Oracle" name. Not that I care for the company, but it makes no sense that oracle and oracledb are taken by 3rd parties. What would make more sense is to permit qualified names associated with an organization or user name. Jtsummers/oracledb would at least not be (easily) confused with an official Oracle product. It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names. Having a single level for naming is just asking for trouble. Between valid name collisions and invalid name squatting, it becomes a much harder problem than necessary.
- teraflop 5y ago
  You'd think this would be common sense (Java solved this problem 25 years ago) but apparently some people are extremely opposed to non-flat package namespaces. See e.g. Rust, where the idea of hierarchical crate namespaces has been politely but firmly shot down every time it's been requested.
  - franciscop 5y ago
    This is only a problem now that npm has millions and millions of packages, IMHO having a flat structure helps in the beginning (abc/jquery vs def/jquery, which one is the official one?) and having a hierarchical structure helps later on.
    - Symbiote 5y ago
      com/jquery. Java 99% solved this decades ago.
    - EdwardDiego 5y ago
      On Java it'd be the com.jquery/jquery. As opposed to io.github.randomperson/jquery.
      - Denvercoder9 5y ago
        Not before it became big. Usually projects start out under some random person GitHub page, and only register domain names later on when it gets traction.
        EdwardDiego 5y ago
        True that, and I've seen packages switch group ids at this point, usually at a major version release. But still makes it easier to verify that you're installing the package you intended. And makes it very hard to deliver typo vulns or squat the "good" names.
        GauntletWizard 5y ago
        And that's fine. A 1.0 release existing as both randomiser/jQuery and jQuery/jQuery is fine, and then 2.0 only exists as jQuery/jQuery; so long as your package manager has good tooling for rewriting imports (and usually sed is enough). Making migration to alternative implementations easy should already be a design goal.
    - mook 5y ago
      The official one of course should be jquery/jquery. Or do it line docker does, and have a reserved official namespace that needs to be whitelisted (that of course has the downside that the people behind the projects don't have direct access and tends to end up with out-of-date packages).
  - swsieber 5y ago
    Java took an approach with one set of trade-offs. Each approach has its pros and cons. > It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names. I do think Rust will get some form of namespaces, but it'll be quite a bit less powerful than what most proponents of namespaces want. There's been a bit of a disagreement (IIRC) about what a namespace signifies (would signify) in the Rust ecosystem. Edit: I will say, it has been quite the contentious and has been re-hashed ad-naseum. For anyone interested in reliving arguments, search for "namespace" on https://internals.rust-lang.org https://internals.rust-lang.org - There will be a good half-dozen results to read through, though there is a fair bit of re-hashing and talking past each other.
- Spartan-S63 5y ago
  Yeah, that makes sense. Basically namespacing on some unique identifier, such as a username/org name. That would alleviate a lot of package squatting concerns.
  - EdwardDiego 5y ago
    Java uses domains. Works great. To use the namespace prefix com.google.XXX you need to control google.com. https://central.sonatype.org/publish/requirements/coordinates https://central.sonatype.org/publish/requirements/coordinate...
  - carols10cents 5y ago
    Wouldn't that move the squatting problem to the unique namespace identifier...?
- pornel 5y ago
  With two-level naming you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`. And if you say just use GitHub user names, you're merely relying on GitHub's support staff to sort it out for you (they're not magic, they have the same problem).
  - merb 5y ago
    > And if you say just use GitHub user names use domains? like java does for over 20 years?
    - nicoffeine 5y ago
      This is one of the things that makes me think Deno will ultimately win: Deno Goals: Simplify the module system - No attempt at compatibility with existing Node modules. - Imports are relative or absolute URLs ONLY. (See Semantic Versioning) - Imports must provide an extension. - Remote URLs are fetched and cached indefinitely on the first load. Only if the --reload flag is provided will the resource be fetched again. - Vendoring can be done by specifying a non-default cache dir. https://tinyclouds.org/jsconf2018.pdf https://tinyclouds.org/jsconf2018.pdf
    - kryptiskt 5y ago
      It has worked terribly, software often live longer than organizations or can easily change hands. And then we get the absurd directory structures, where half the code lives in com/oldcompanyname and half in com/newcompanyname and related code can be far away. Even Sun went away and left nothing but a bunch of legacy package names.
  - thaumasiotes 5y ago
    > With two-level naming you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`. The same way that Java packaging is nothing but a big fight over who owns "com.*"?
    - pornel 5y ago
- alpaca128 5y ago
  Why not go the BattleNet route and just allow any name collision but appending something unique to every instance of the name? In BattleNet's case it was a number, but with dependencies it might make more sense to add random words to avoid confusion. So there could be a "foo#cat" and a "foo#dog", and those names can remain unchanged forever. Or maybe go for alphanumeric IDs, though I think those would be much harder to tell apart.
  - deleted 5y ago
    [deleted]
Borgz 5y ago
I agree. A good place to start might be requiring email verification to publish a package so that the registry is more likely to have valid email addresses for maintainers.
k__ 5y ago
Is this really an issue? Who cares if they have to install oracle or @oracle/client?

by l0b0 5y ago

Jtsummers 5y ago

Shallow, unqualified naming is part of the issue here. Look up, for instance, anything with the "Oracle" name. Not that I care for the company, but it makes no sense that oracle and oracledb are taken by 3rd parties. What would make more sense is to permit qualified names associated with an organization or user name. Jtsummers/oracledb would at least not be (easily) confused with an official Oracle product. It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names. Having a single level for naming is just asking for trouble. Between valid name collisions and invalid name squatting, it becomes a much harder problem than necessary.

teraflop 5y ago
You'd think this would be common sense (Java solved this problem 25 years ago) but apparently some people are extremely opposed to non-flat package namespaces. See e.g. Rust, where the idea of hierarchical crate namespaces has been politely but firmly shot down every time it's been requested.
- franciscop 5y ago
  This is only a problem now that npm has millions and millions of packages, IMHO having a flat structure helps in the beginning (abc/jquery vs def/jquery, which one is the official one?) and having a hierarchical structure helps later on.
  - Symbiote 5y ago
    com/jquery. Java 99% solved this decades ago.
  - EdwardDiego 5y ago
    On Java it'd be the com.jquery/jquery. As opposed to io.github.randomperson/jquery.
    - Denvercoder9 5y ago
      Not before it became big. Usually projects start out under some random person GitHub page, and only register domain names later on when it gets traction.
      - EdwardDiego 5y ago
        True that, and I've seen packages switch group ids at this point, usually at a major version release. But still makes it easier to verify that you're installing the package you intended. And makes it very hard to deliver typo vulns or squat the "good" names.
      - GauntletWizard 5y ago
        And that's fine. A 1.0 release existing as both randomiser/jQuery and jQuery/jQuery is fine, and then 2.0 only exists as jQuery/jQuery; so long as your package manager has good tooling for rewriting imports (and usually sed is enough). Making migration to alternative implementations easy should already be a design goal.
  - mook 5y ago
    The official one of course should be jquery/jquery. Or do it line docker does, and have a reserved official namespace that needs to be whitelisted (that of course has the downside that the people behind the projects don't have direct access and tends to end up with out-of-date packages).
- swsieber 5y ago
  Java took an approach with one set of trade-offs. Each approach has its pros and cons. > It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names. I do think Rust will get some form of namespaces, but it'll be quite a bit less powerful than what most proponents of namespaces want. There's been a bit of a disagreement (IIRC) about what a namespace signifies (would signify) in the Rust ecosystem. Edit: I will say, it has been quite the contentious and has been re-hashed ad-naseum. For anyone interested in reliving arguments, search for "namespace" on https://internals.rust-lang.org https://internals.rust-lang.org - There will be a good half-dozen results to read through, though there is a fair bit of re-hashing and talking past each other.
Spartan-S63 5y ago
Yeah, that makes sense. Basically namespacing on some unique identifier, such as a username/org name. That would alleviate a lot of package squatting concerns.
- EdwardDiego 5y ago
  Java uses domains. Works great. To use the namespace prefix com.google.XXX you need to control google.com. https://central.sonatype.org/publish/requirements/coordinates https://central.sonatype.org/publish/requirements/coordinate...
- carols10cents 5y ago
  Wouldn't that move the squatting problem to the unique namespace identifier...?
pornel 5y ago
With two-level naming you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`. And if you say just use GitHub user names, you're merely relying on GitHub's support staff to sort it out for you (they're not magic, they have the same problem).
- merb 5y ago
  > And if you say just use GitHub user names use domains? like java does for over 20 years?
  - nicoffeine 5y ago
    This is one of the things that makes me think Deno will ultimately win: Deno Goals: Simplify the module system - No attempt at compatibility with existing Node modules. - Imports are relative or absolute URLs ONLY. (See Semantic Versioning) - Imports must provide an extension. - Remote URLs are fetched and cached indefinitely on the first load. Only if the --reload flag is provided will the resource be fetched again. - Vendoring can be done by specifying a non-default cache dir. https://tinyclouds.org/jsconf2018.pdf https://tinyclouds.org/jsconf2018.pdf
  - kryptiskt 5y ago
    It has worked terribly, software often live longer than organizations or can easily change hands. And then we get the absurd directory structures, where half the code lives in com/oldcompanyname and half in com/newcompanyname and related code can be far away. Even Sun went away and left nothing but a bunch of legacy package names.
- thaumasiotes 5y ago
  > With two-level naming you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`. The same way that Java packaging is nothing but a big fight over who owns "com.*"?
  - pornel 5y ago
alpaca128 5y ago
Why not go the BattleNet route and just allow any name collision but appending something unique to every instance of the name? In BattleNet's case it was a number, but with dependencies it might make more sense to add random words to avoid confusion. So there could be a "foo#cat" and a "foo#dog", and those names can remain unchanged forever. Or maybe go for alphanumeric IDs, though I think those would be much harder to tell apart.
- deleted 5y ago
  [deleted]

Borgz 5y ago

I agree. A good place to start might be requiring email verification to publish a package so that the registry is more likely to have valid email addresses for maintainers.

k__ 5y ago

Is this really an issue? Who cares if they have to install oracle or @oracle/client?