Re-support same-host http-to-https redirect

[brandtkeller]

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

1. ORAS sends an unauthenticated request to http://registry.example.
2. The server responds with a redirect to https://registry.example.
3. ORAS follows the redirect without an Authorization header.
4. The HTTPS endpoint responds with a normal Basic or Bearer 401 challenge.
5. 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.

[github-actions]

This issue is stale because it has been open for 60 days with no activity. Remove the stale label or comment to prevent it from being closed in 30 days.