[release/9.0.1xx] AuthHandshakeMessageHandler: sync behavior with other clients. #43942
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
- Removes the special handling of the '<token>' username. This value is used as a sentinel from credential-helper scripts/programs. It is already handled by the docker-creds-provider .NET library. - When there is no identity token, use the username/password with Basic auth.
dotnet-issue-labeler
bot
added
Area-Infrastructure
untriaged
|
@dotnet/source-build the sdk-source-build leg has failed repeatedly here when initializing the VMR - is there something we can to do to in this PR to fix this, or is there some other solution? |
There were conflicting changes made a few days ago. This has been addressed so a simple update from the target branch should address the issue. I updated the branch for you. |
|
So simple :) thanks @MichaelSimons! |
test/Microsoft.NET.Build.Containers.UnitTests/AuthHandshakeMessageHandlerTests.cs
Show resolved
Hide resolved
src/Containers/Microsoft.NET.Build.Containers/AuthHandshakeMessageHandler.cs
Show resolved
Hide resolved
src/Containers/Microsoft.NET.Build.Containers/AuthHandshakeMessageHandler.cs
Show resolved
Hide resolved
|
Good to go, pending a discussion about change scope and risk management for the backport. |
|
@baronfel checking in on 9.0.1xx backport PRs to see if they are needed for 9.0.1xx GA and ready to go. |
|
Yeah, this is good to go but we're nailing down a bit of scope. Give us another day? |
Backport of #43491 to release/9.0.1xx
Description / Customer Impact
Customers attempting to authenticate against OpenShift registries experience authentication failures because of an interesting spec quirk around the use of Identity Tokens. This PR introduces a fallback mechanism at a lower priority than our current scheme to try a quirked behavior for such registries. This logic is based on analysis of other widely-used containers tooling like Podman, Docker, and the
regclientlibrary for Go.Regression
No - non-identity token logins work for such registries, this is a support gap.
Risk
Low - the fallback only happens if the identity token pathway is not valid for a particular domain. There is a scenario that looks from the code that we might regress, but in real world scenarios that pathway doesn't ever present itself.
Testing
A broad set of authentication mocks have been created based on test suites and registries that we support today that lets us cover the entire matrix of auth - this is a huge amount of additional testing that is a great foundation for future validation.
In addition, I tested the original version of this PR against a broad set of registries over at baronfel/sdk-container-demo and there were no regressions. I did not have an OpenShift registry to test against, but @tmds has done this.
Workaround
There is no workaround for users using our tooling exclusively, the main workaround would be to include external tooling like Docker and have the SDK push to those locations before using Docker et al to push to the final destination.
/cc @baronfel @tmds