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.
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?
Yes, it will output something like this:
netrc file not updated. Please remove credentials from the file manually.
- 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
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.
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.
Could you please elaborate on how the
security command is fragile?
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.
True, being able to use environment variables seems like a good compromise to me.
Env vars are good, but how it would be implemented in this case (per server basis)?
Time is running out, are there any ideas how to deal with this? Thanks
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?
@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.
@mdvorak Got it. We will likely have some way for users to override the default so they can use netrc if they choose.