OK, Iāll attempt to do that.
The current ecosystem lacks a way for projects with many packages to signal a verified pattern of ownership.
Incorrect. Using an informal naming convention is an initial indicator, and combining this with checking the project author detail achieves this. It might not be simple to do this, but the proposed mechanism, with the need to allow pre-existing projects to remain in a reserved namespace, honestly doesnāt seem that much better.
(Typeshed has been discussed to death, so Iāll skip that example)
Major cloud providers like Amazon, Google and Microsoft have a common prefix for each featureās corresponding package
Have they indicated that the current situation is a problem for them? Can representatives participate in this thread to make their case? I donāt think itās unreasonable to expect community participation if they want to support this feature. And conversely, if they arenāt willing to engage with the community, I donāt think we should be expected to infer and implement their requirements.
Many projects support a model where some packages are officially maintained and third-party developers are encouraged to participate by creating their own. For example, Datadog offers observability as a service for organizations at any scale.
Iām sorry, and I donāt want to suggest any hidden agenda either on your part or on Datadogās, but I honestly think that using Datadog as a motivating example in a PEP thatās being proposed directly as part of work that they are funding, is ill-advised. If the proposal has merit, then finding other examples would be much less controversial. This isnāt a matter of distrust, itās simply a case of ensuring that the motivation section of the PEP is as compelling as possible to the audience reading it - which is mostly (at this point) the open source volunteer community.
Such projects are uniquely vulnerable to name-squatting attacks which can ultimately result in dependency confusion.
We have PEP 708 which is designed to mitigate dependency confusion. This proposal needs to describe how it relates to that one. My impression is that this is more about typosquatting attacks, and as others have said, it only addresses vulnerabilities related to one very particular class of typo.
For example, say a new product is released for which monitoring would be valuable. It would be reasonable to assume that Datadog would eventually support it as an official integration.
Itās also entirely reasonable to assume that 3rd parties could produce safe, useful integrations. By blocking of the āofficialā namespace, those 3rd party integrations would have to use unrelated names (unless Datadog creates some form of ācontribā area, which is then just as vulnerable to malicious projects as the current open namespace). So users looking for integrations will get used to the idea of useful integrations having names outside of the Datadog namespace, negating the benefit of having an āofficialā namespace.
To be clear, I see the advantage here, I just think itās relatively small, and not compelling, because itās at best a partial mitigation for a small class of attacks. I think we should aim to do better than this, if we want to address this problem.
Namespacing also would drastically reduce the incidence of typosquatting because typos would have to be in the prefix itself which is normalized and likely to be a short, well-known identifier like aws-.
Do you have any evidence to support this? You mention the cupy-cuda case, but that seems to have been one instance (registering a lot of packages, certainly, but still only a single attack). Iād imagine there are at least as many typosquatting attacks against popular projects that donāt use a namespace-style name (like requests or flask). Without data, this statement is basically just speculation.
In contrast, the PEP says basically nothing about the potential risks of the proposal. It assumes ācorporate organisationsā are stable entities, and can be trusted to make reasonable use of the feature. While this may be true for the given examples, it ignores (for example) the possibility of ill-conceived startups grabbing a namespace based on speculative plans and VC funding, then burning out or changing direction and leaving a bunch of reservations that (as stated) the PEP has no means of dealing with.
Hopefully, the above is useful. Iām not a fan of this proposal as it stands, but I know thereās a need for something in this area. So if this helps in developing a more acceptable solution, then thatās great. And TBH, if it helps to clarify weaknesses in the existing proposal, even if that means the PEP fails and weāre left still looking for a solution, Iām OK with that outcome as well.
Nope, Iām not going to do this. Iām not at all convinced that āminimal ecosystem disruptionā is the key constraint here. If the problemās important enough to need a solution, we should come up with the best solution we can, and work out how to handle the ecosystem disruption, not settle for a suboptimal solution just because it can be shoehorned into the existing infrastructure.
And doing nothing is absolutely a valid alternative. After all, thatās what PEP rejection would be. So my proposed alternative at the moment is āreject the PEP, i.e. do nothing until a better proposal comes alongā.
If I have to discuss alternatives, I think we should be taking a much longer-term view. That may not fit well with the amount of time you have funded to work on this, but I donāt think that should be the driver here. If we need to implement a solution that needs a multi-year migration process, then thatās fine. Weāve done that many times before, and itās worked perfectly well. Slower than anyone might like, but the end result is what matters.
