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?
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.
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.
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.
@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.