Revamp credential storage system to allow for smarter searching #162

Update the ICredentialStore and ICredential API to allow for smarter searching of stored credentials. The new API exposes filtering by "service name" and "account" separately. Service name will typically be the URL the credential is stored against, and the account will be the username associated with the credential.

Update the macOS Keychain component implementation to match the new ICredentialStore interface. We now use the `SecItemCopyMatching` to perform a general query for items, and return a specialised credential object including all relevant attributes.

Update the Windows Credential Manager component to implement the new ICredentialStore interface, including credential enumeration and matching by account/user as well as 'service name' (target).

Recover the correct service name from the target name. Since the target name may contain a userinfo component (for example https://alice_domain.com@example.com/path), and the only place we store the service name is in the target name, we need to strip out any userinfo component. We do this by looking for the "://" and the first '@' character before the first '/', which act as the start and end of the userinfo component.

Update the SecretServiceCollection credential store (backed by libsecret) to match the new ICredentialStore interface and access model.

Update the remote URI generation from the program InputArguments to support port numbers, and special characters in usernames.

Update the HostProvider base class to use the new 'service name' abstraction rather than the simple 'unique credential key' one. With this model we can better issue credential storage queries where the username may not be specified explicitly in a get request (often the case as the username is not always included in the remote URL for many services).

Update the generic host provider to support the new credential storage model and HostProvider base class APIs.

Update the Basic authentication component to match the new ICredential interface.

Update the BitBucket provider to support and implement the new credential storage/recall model and APIs.

Update the GitHub provider to implement and follow the new credential storage/recall/matching model and ICredentialStore APIs.

Update the Azure Repos provider to support the new credential storage API/model, as well as support remote URLs with explicit port numbers.

Now that we support multiple user accounts for each host/service/remote, we have hit an interesting issue with Azure Repos. With the introduction of the dev.azure.com-style URLs for Azure Repos there was an unfortunate hack or workaround invented to add the AzDevOps org name to the userinfo part of the remote URL, for example: org@dev.azure.com/org/blah. Since GCM for Windows (and older versions of GCM Core that initially followed the same model) always uses the value "PersonalAccessToken" for the username field when storing credentials it was free to ignore the user part of the input. The problem now is that since we support multiple user accounts, and will perform an exact match against the credential (with user) if a username is specified in the remote URL, we never find the credential we now store (we now always store with the actual, real users' UPN). To workaround this workaround (yuck) we ignore the username IF AND ONLY IF the host is dev.azure.com, and return the first matching dev.azure.com/org credential. The upshot of this is that dev.azure.com-style URLs do NOT support multiple users OR full paths, however vs.com-style URLs will.

Add support for customising the namespace/prefix used to store credentials in the OS credential store. By default we use "git:{service}". Users can use GCM_NAMESPACE or credential.namespace to set this to something different. These configuration options are the same as in GCM for Windows to help with migration.

Update the GCM Core Host Provider spec document and architecture document to reflect the changes made to the abstract HostProvider class; replacing GetCredentialKey with GetServiceName.

Fix a bug in the WindowsEnvironment implementation of the LocateExectuable method. On .NET Core the UseShellExecute property of ProcessStartInfo defaults to false, whereas on .NET Framework (the runtime that we target on Windows) defaults to true. You must set this to false if you want to redirect standard streams (which we want to do). The .NET Framework-targeting build on Windows was throwing an exception here(!)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Revamp credential storage system to allow for smarter searching #162

Revamp credential storage system to allow for smarter searching #162

Commits on Sep 17, 2020