URLs as Swift Package Identifiers

[xwu (Xiaodi Wu)]

@mattt

I don't want to diminish the potential for ambiguity or complexity in parsing URIs. However, I do think it's important to focus on how package identifiers would be used.

@mattt

Any dependency URLs declared in Package.swift were put there by the developers authoring that package. Any transitive dependencies were put there by the maintainers of those direct dependencies. Would you say that the potential for security exploits due to URI parsing ambiguity is distinct from those inherent from importing 3rd-party code?

Forgive me if I misread the core team’s prompt. But the following text reads to me like the topic here is about much more than how Swift package identifiers will be used in this proposal:

1. Package identities are a critical component of this proposal and the Swift package ecosystem. When the core team discussed the various opinions brought up in the review regarding using URLs as identities compared to name-spaced identities @Douglas_Gregor brought up the point that using a stable and unique name-spaced package identity would also provide the infrastructure to resolve module name conflicts (e.g. Namespacing of packages/modules, especially regarding SwiftNIO ), which would be a great benefit to the ecosystem. This topic needs to be further explored in a dedicated forum thread in preparation to the next revision.

An identity for the ecosystem which is to be used as infrastructure to solve other problems, which is what the core team wants to talk about, would necessarily be more than what you’re talking about here.

And the problem I have is if we are to use URIs to which the proposed heuristics are applied to be that identity for the ecosystem, then it does not meet the requirements for an identifier at face value, those being (it would seem to me, perhaps naively):

• Every package should have one and only one identifier
• Every identifier should correspond to one and only one package

The heuristics proposed here for URIs partly reduce the number of identifiers for one package, but as others mention, if the package moves from GitHub to GitLab, then the heuristics are not enough.

What causes me heartburn, though, is that if normalization rules are not chosen correctly (i.e., consistently with the tools that will actually resolve the URIs and fetch the code), the same identifier could identify more than one package. This may not be an issue for what you propose here, but it does not seem to me to be a suitable identity for the ecosystem. And if that’s what the core team wants out of it, I think we need to discuss alternatives.