Description
Surfacing this more as a question initially to feel out whether a change is required. With the fix for GHSA-vh4v-2xq2-g5cg I noticed that we were getting errors for a scenario that I feel is orthogonal to the security finding and not explicitly within the scope.
Scenario
The v2.6.1 fix for GHSA-vh4v-2xq2-g5cg correctly prevents Authorization from being forwarded across an HTTP-origin change. However, it also prevents auth.Client from handling an authentication challenge received after a narrow, safe upgrade path:
http://registry.example → https://registry.example
Observed workflow
- ORAS sends an unauthenticated request to
http://registry.example.
- The server responds with a redirect to
https://registry.example.
- ORAS follows the redirect without an
Authorization header.
- The HTTPS endpoint responds with a normal Basic or Bearer
401 challenge.
auth.Client.Do() sees that the final response URL differs in scheme from the original URL and returns the 401 unchanged.
Additional context
We fixed this upstream with a negotiation workflow for determining https - so we're not blocked on this change - but it was a large enough change in behavior to warrant looking at the root cause (we work with a lot of managed and local infrastructure pulling/pushing from many distinct registries in a single execution.
If this feels within the boundary of acceptable - feel free to assign to me or handle as you see fit. Otherwise not opposed to an answer of "not in scope" anymore.
Description
Surfacing this more as a question initially to feel out whether a change is required. With the fix for GHSA-vh4v-2xq2-g5cg I noticed that we were getting errors for a scenario that I feel is orthogonal to the security finding and not explicitly within the scope.
Scenario
The v2.6.1 fix for GHSA-vh4v-2xq2-g5cg correctly prevents
Authorizationfrom being forwarded across an HTTP-origin change. However, it also preventsauth.Clientfrom handling an authentication challenge received after a narrow, safe upgrade path:Observed workflow
http://registry.example.https://registry.example.Authorizationheader.401challenge.auth.Client.Do()sees that the final response URL differs in scheme from the original URL and returns the401unchanged.Additional context
We fixed this upstream with a negotiation workflow for determining https - so we're not blocked on this change - but it was a large enough change in behavior to warrant looking at the root cause (we work with a lot of managed and local infrastructure pulling/pushing from many distinct registries in a single execution.
If this feels within the boundary of acceptable - feel free to assign to me or handle as you see fit. Otherwise not opposed to an answer of "not in scope" anymore.