SE-0378: Swift Package Registry Authentication

tomerd · 2022-11-14T21:39:44.921Z

The review of SE-0378: Swift Package Registry Authentication, begins now and runs through Dec 2nd, 2022.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager or direct message in the Swift forums).

What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.

When reviewing a proposal, here are some questions to consider:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you for helping improve the Swift programming language and ecosystem.

Tom Doron
Review Manager

xwu · 2022-11-14T22:04:53.599Z

To avoid accidental removal of sensitive data, .netrc file needs to be updated manually by the user.

Will there be a prompt at logout time to remind the user of this fact?

yim_lee · 2022-11-14T22:21:26.989Z

xwu:

Will there be a prompt at logout time to remind the user of this fact?

Yes, it will output something like this:

netrc file not updated. Please remove credentials from the file manually.

mdvorak · 2022-11-15T13:51:05.372Z

SwiftPM will perform lookups in one credential store only. For macOS, it will be Keychain. For all other platforms, it will be the user-level .netrc file.

Would it be possible to retain support for netrc file as a credential source on all platforms? For automation environment (CI etc), it is much easier to manage, and it is used by several other tools (curl including).

Example from another tool is NuGet - it uses secure store to encrypt passwords on Windows, but it supports clear text passwords on all platforms as well.

Jon_Shier · 2022-11-15T18:27:29.532Z

Yes, given there's no official workflow from Apple for deploying keychains as part of a build system, how exactly does Apple expect this to work? Even when we make them manually work through the security command or Fastlane wrapper, they're very fragile and hard to debug, making them a rather poor solution even at the best of times. There needs to be a pragmatic approach here.

NeoNacho · 2022-11-15T19:35:46.293Z

Jon_Shier:

Even when we make them manually work through the security command or Fastlane wrapper, they're very fragile and hard to debug

Could you please elaborate on how the security command is fragile?

Jon_Shier · 2022-11-15T22:46:26.267Z

Perhaps it's not the command itself but the results of it interacting with a keychain that are fragile. Most notably, in environments that aren't entirely blown away, like dedicated builders, there seems to be some sort of keychain caching. Updated keychain files with the same file name aren't actually opened in a way that makes their updated contents properly available. I've had to make various hacks where the keychain is copied to a file with a random name and then opened for the updated items to be properly visible.

There are also other keychain issues with the security command, like no proper separation between add / delete and lock / unlock, as well as issues around the interaction with Keychain Access where keychains which have be installed and then deleted are still visible in the UI.

A third issue is that some CI systems, like GitHub Actions, don't support proper secure file injection. Instead, the keychain is base64 encoded as a secret string and then decoded to disk and opened in the builder. Being able to provide environment values directly would be much nicer.

NeoNacho · 2022-11-15T22:49:00.249Z

Jon_Shier:

Being able to provide environment values directly would be much nicer.

True, being able to use environment variables seems like a good compromise to me.

mdvorak · 2022-11-16T12:39:56.102Z

Env vars are good, but how it would be implemented in this case (per server basis)?

mdvorak · 2022-11-27T07:47:16.392Z

Time is running out, are there any ideas how to deal with this? Thanks

yim_lee · 2022-11-28T01:10:11.768Z

Would it be possible to retain support for netrc file as a credential source on all platforms?

@mdvorak This is what you are asking for primarily, correct?

mdvorak · 2022-11-28T09:23:22.391Z

@yim_lee To be precise, problematic is SwiftPM will perform lookups in one credential store only, but yeah, thats about it.
If I remember that correctly, desired behavior (with fallback) is a current implementation, and this change removes it.

yim_lee · 2022-11-28T17:01:54.859Z

@mdvorak Got it. We will likely have some way for users to override the default so they can use netrc if they choose.

tomerd · 2023-01-14T02:58:46.410Z

SE-0378 has been accepted with modification. If you'd like to continue discussing this, please do so in that thread.

tomerd · 2023-01-14T02:58:51.236Z