GCM Release 2.2.2 #1333
Merged
GCM Release 2.2.2 #1333
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixed path for user-only installation of GCM for Windows. Seems #551 forgot to update this path. version: v2.1.2 imagePath: `C:\Users\user` ``` $ git config --global credential.helper "/mnt/c/Users/user/AppData/Local/Programs/Git\ Credential\ Manager/git-credential-manager.exe" $ git pull Already up to date. ```
Update the current VERSION placeholder for the git-credential-manager-core to git-credential-manager rename to 2.0.877 (the version with which this update was released).
Update the current VERSION placeholder for the git-credential-manager-core to git-credential-manager rename to 2.0.877 (since that is the version with which this update was released). Fixes #1318
Ensure that we read helper UI standard output as UTF-8. Helper applications already write output with a UTF-8 encoding, so we must ensure we read using the same encoding in the core application or else non-ASCII characters may be mangled.
Ensure that we read helper UI standard output as UTF-8. Helper applications already write output with a UTF-8 encoding, so we must ensure we read using the same encoding in the core application or else non-ASCII characters may be mangled. Fixes #1287
GCM by default creates entries in the Windows Credential Manager on Windows, and prefixes the 'target name' of the entry with "git:". This 'namespace' prefix is configurable, but is not often changed in practice outside of tests. Visual Studio, when adding GitHub accounts (either natively or by the older GitHub extension for VS), it creates three credential entries: 1. GitHub for Visual Studio - https://github.com 2. git:https://github.com 3. https://github.com Entry 1 is used by VS for it's own purposes. Entry 2 is created for the benefit for GCM, so that we are 'primed'. It is unknown what entry 3 is for at this time. There is an error in our existing logic for enumerating credentials that is also matching entry 3 as well as the expected entry 2. Modify and fix the matching logic to ensure that the namespace prefix matches, rather than just stripping it and matching (even if it doesn't exist!).
For GitHub.com we've updated the redirect URI to 127.0.0.1, whilst also keeping the localhost variant around for backwards compatibility with older GCM clients. However, since GHES has not been updated with the new 127.0.0.1 redirect, and older GHES servers will be stuck with the old redirect we must continue to use the localhost redirect on the client for non-dotcom targets.
For GitHub.com we've updated the redirect URI to 127.0.0.1, whilst also keeping the localhost variant around for backwards compatibility with older GCM clients. However, since GHES has not been updated with the new 127.0.0.1 redirect, and older GHES servers will be stuck with the old redirect we must continue to use the localhost redirect on the client for non-dotcom targets. Fixes #1329
…redential Manager (#1328) GCM by default creates entries in the Windows Credential Manager on Windows, and prefixes the 'target name' of the entry with "git:". This 'namespace' prefix is configurable, but is not often changed in practice outside of tests. Visual Studio, when adding GitHub accounts (either natively or by the older GitHub extension for VS), it creates three credential entries: 1. GitHub for Visual Studio - https://github.com 2. git:https://github.com 3. https://github.com Entry 1 is used by VS for it's own purposes. Entry 2 is created for the benefit for GCM, so that we are 'primed'. It is unknown what entry 3 is for at this time. There is an error in our existing logic for enumerating credentials that is also matching entry 3 as well as the expected entry 2. Modify and fix the matching logic to ensure that the namespace prefix matches, rather than just stripping it and matching (even if it doesn't exist!). Fixes #1325 --- **Bug repro instructions:** 1. Open Visual Studio 2. File > Account Settings 3. Add a GitHub account 4. Open a terminal (inside or outside of VS) and attempt to clone/fetch/push to or from a private GitHub repository. At this point a window should appear asking you to select between two "Personal Access Token" accounts. After installing [the bits from this PR build (artifacts > win-x86)](https://github.com/git-ecosystem/git-credential-manager/pull/1328/checks), attempting step 4 should **no longer** result in a prompt to select between two "Personal Access Token" accounts.
Before 2.2.0, we only accepted input arguments in the form key=value. To support the new wwwauth[] argument from Git, we added support for these multi-value args key[]=value. In changing from an dictionary of string:string to string:list<string> we accidentally changed the behaviour of dictionary parsing in the case that an empty valued argument was provided. For example: username=\n Preivously this was returned as an empty string. Post 2.2.0 this became `null`, causing an error in scenarios were before there was none. One such scenario is with Windows Integrated Authentication (for example when connecting to Azure DevOps Server/TFS instances), whereby we return an empty username and password to Git to signal this auth mode. Git then returns to us the empty username and password in a `store` call. Update the handling in `ParseMultiLine` to restore the previous behaviour for empty-valued arguments being mapped to the empty string.
Before 2.2.0, we only accepted input arguments in the form `key=value`. To support the new `wwwauth[]` argument from Git, we added support for these multi-value args `key[]=value`. In changing from an dictionary of `string:string` to `string:list<string>` we accidentally changed the behaviour of dictionary parsing in the case that an empty valued (non-multi) argument was provided. For example: ```text username=\n ``` Previously this was returned as an empty string. Post 2.2.0 this became `null`, causing an error in scenarios were before there was none. One such scenario is with Windows Integrated Authentication (for example when connecting to Azure DevOps Server/TFS instances), whereby we return an empty username and password to Git to signal this auth mode. Git then returns to us the empty username and password in a `store` call. Update the handling in `ParseMultiLine` to restore the previous behaviour for empty-valued arguments being mapped to the empty string. Fixes #1331 --- **Bug reproduction steps:** ```console % printf "url=https://example.com\nusername=\npassword=\n\n" | git credential approve fatal: Missing 'username' input argument ```
mjcheetham
requested review from
derrickstolee,
vdye,
jeffhostetler and
ldennington
vdye
approved these changes
Jul 12, 2023
ldennington
approved these changes
Jul 12, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes since 2.2.1:
localhost:80instead of127.0.0.1:60167#1329 Use localhost redirect URI for GHES instances #1330)