Support for non-HTTPS localhost registries

[Footpad]

Description

My work involves using an SwiftPM Registry service hosted locally on my developer machine. This is an important requirement for our development workflow and internal policies.

Up until SE-0392 was implemented, we had to write our own tooling for publishing SwiftPM packages to our registry. Now that the swift CLI has a command for publishing a package to a registry, we would like to be able to deprecate our homegrown tooling in favor of the built-in swift package-registry publish command.

However, we cannot start this migration because swift package-registry publish validates that the given registry starts with HTTPS, and our localhost SwiftPM registry can only support HTTP.

It is not tractable for us to add HTTPS support to our localhost registry, unless using self-signed certificates. I suspect (but was unable to confirm) that the HTTP client SwiftPM uses would reject self-signed certificates, and require TLS verification (If self-signed certificates would be supported, I'm happy to resolve this as a non-issue). Setting up a proper Certificate Authority and key distribution mechanism to be used on our developer machines to pass TLS verification would be extremely costly and does not significantly improve security posture.

While I applaud that SwiftPM has taken a "secure by default" approach for registries in this regard, we should also recognize the risks of not being able to reuse SwiftPM's own tooling for publishing for our use case. If we're not able to use the swift package-registry publish command, we have to continue having our own implementation which has already fallen behind with respect to things like support for package signing. Bespoke implementations may also have flaws that impact the security or correctness of publishing.

I would like to contribute a change to SwiftPM that would allow us to adopt the publishing command in the future, and I am looking for feedback regarding two potential paths to enable my use case:

1. Don't enforce the HTTPS requirement if the registry host URL component is localhost, 127.0.0.1, or ::1. This is the most simple, but has the downside of skirting the principle of least surprise depending if you have the localhost registry use case or not.
2. Expose an option for users to allow HTTP registries. There's a few ways this could work such as environment variables or CLI flags, but I think a per-registry configuration in the existing registries.json would have the least risk of being used unintentionally.

[yim-lee]

@Footpad I assume your local registry does not require authentication?

What do we think of the following?

1. swift package-registry set and publish subcommands will have a new allow-http flag, which must be set when passing a HTTP URL or if the computed registry URL is HTTP (e.g., publish computes registry URL if one is not provided).
2. For publish, in addition to (1), the registry must not require authentication if URL is HTTP. i.e., the authentication block in registries.json config file must not contain entry for the registry.
3. The login subcommand will continue to require HTTPS.

[yim-lee]

Tracking with rdar://119403494

[Footpad]

@yim-lee Yes, our local registry does not use authentication - without going into proprietary details, authN and authZ aspects are handled elsewhere on the local service out-of-band of the registry API.

I think the proposal you have makes sense to me:

• I concur with the concern to prohibit authentication in the HTTP case - we don't want to unwittingly have registry credentials transmitted in HTTP plaintext. Login primarily deals with credentials (we don't use it in our use case), so requiring HTTPS there is good.
• Regarding the naming of a new allow-http flag, I was originally thinking something like allow-insecure-http. I personally like when I see insecure in an option name like this because it raises the question of "why?" when it's used and forces the user to think twice about using it. I would of course understand if using such language is not preferred.

[yim-lee]

Regarding the naming of a new allow-http flag, I was originally thinking something like allow-insecure-http.

allow-insecure-http is good! Let's use it. :)