[release/8.0.4xx] [Containers] Fix insecure registry handling to use the correct port for the HTTP protocol #44234
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
dotnet-issue-labeler
bot
added
Area-Infrastructure
untriaged
baronfel
changed the title
baronfel
approved these changes
Oct 16, 2024
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.
Backport of #44050 to release/8.0.4xx
Description/Customer Impact
Users pushing images to 'insecure registries' (which are managed via Docker/Podman configuration) couldn't successfully push to those registries if they used HTTP (as opposed to an untrusted/self-signed/etc HTTPS certificate). This was because when constructing the fallback HTTP url for the registry we used UriBuilder to copy over all parts of Uri and just change the
scheme. Due to vagaries of the UriBuilder APIs, this meant that we always used the HTTPS port (443) for these HTTP uris, which results in communication errors. This change updates the way we construct the HTTP Uris for our HTTP fallback logic for insecure registries to allow HTTP communication with these registries by not using the HTTPS port unless the registry configuration explicitly pinned the port to be used.Regression
No - this is fixing a gap that we didn't have test coverage in on the initial 'insecure registry' support
Risk
Low - we have automated test coverage for this scenario, and this only applies to users of the 'insecure registry' feature (which was only recently released in 8.0.400 and we have not received huge amounts of negative feedback on).
Testing
Automated tests for a wide variety of potential registry names and configurations was added.
/cc @baronfel @dameng324