[Returned for revision] SE-0292: Package Registry Service

tomerd · 2020-12-28T21:33:20.893Z

The review of SE-0292: Package Registry Service has concluded and the core team has returned it for revision.

The feedback to the idea of defining an open-standard Package Registry HTTP based API, and implementing support for it in SwiftPM as an alternative to resolving dependencies via git, was very positive. However, there were a number of follow-on questions and concerns that came up during the review that the core team feels require further refinement:

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.
Publishing packages has a large degree of variation across software used to host packages / artifacts. As such, the proposal should either:
- Explicitly call out publishing was deliberately left undefined in the spec and left for each registry to define.
- Or
  - Define optional extension for publishing signed sources.
  - Modify “poke” publishing with hash information, or other information that can help provide additional layer of security / authenticity.
The proposal should define a new configuration for intermediate registries (e.g. proxies, behind-the-firewall registries), and touch on how it interplays and/or eventually replaces mirrors.
The proposal should discuss the performance of HTTP based resolution compared to git based one, explain how fine tuned API calls for retrieving Package.swift and ToolsVersion can be (or are) faster than the equivalent git operations and reference benchmarks done.
The proposal should mention how private packages could be addressed (e.g. using a registry that supports publishing source or continuing to use git).
The proposal should go into a bit more details in the security section about how transparent-logs compare to package signing; How SwiftPM could work with a transparent-log once such exists; And how transparent-log will interact with registries to retrieve the source or otherwise compute the hashes. Since this proposal leaves the security aspects of the package ecosystem to future proposals, there is no need for a complete design here, just enough to clarify the future direction.

mattt · 2020-12-28T22:27:26.279Z

Thanks for writing this up, @tomerd. It's been a pleasure working with you throughout this process, and I look forward to addressing the outstanding concerns from the Swift core team about this proposal.

We've started working on a revision to our original proposal based on this feedback. You can find the latest version here.

In response to the first point of feedback:

tomerd:

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.

I think that's a great idea. I've started a new thread to discuss this topic further. I invite anyone interested in this topic to help us develop a robust solution that addresses our current and prospective needs.