Bump oras-go to v2.7.0: OCI HelmRepository pulls fail when the token realm resolves to a private IP (DigitalOcean DOCR from DOKS) #2230

Summary

Since source-controller v1.10.x, an OCI HelmRepository (spec.type: oci) cannot pull charts from DigitalOcean Container Registry (DOCR) when source-controller runs on DigitalOcean Kubernetes (DOKS). The chart pull fails while fetching the bearer token:

chart pull error: failed to download chart for remote reference: failed to get 'oci://registry.digitalocean.com/<registry>/charts/<chart>:<version>':
failed to perform "FetchReference" on source: GET "https://registry.digitalocean.com/v2/<registry>/charts/<chart>/manifests/<version>":
bearer realm host "api.digitalocean.com" resolves to 10.100.15.254, a loopback, link-local, private, unspecified, or carrier-grade NAT address

Cause

• DOCR answers with WWW-Authenticate: Bearer realm="https://api.digitalocean.com/v2/registry/auth",....
• Inside DOKS, DigitalOcean's DNS resolves api.digitalocean.com to an internal RFC 1918 address. Outside, it resolves to public Cloudflare IPs.
• source-controller v1.10.1 pins oras.land/oras-go/v2 v2.6.4. Its realm validation (GHSA-xf85-363p-868w) rejects any realm that resolves to a private address, and offers no way to configure that.
• This is v2.6.4 broken with RFC1918 IPs oras-project/oras-go#1631 ("v2.6.4 broken with RFC1918 IPs"). It was fixed by feat(auth): make the bearer realm address denylist configurable oras-project/oras-go#1632, released in oras-go v2.7.0 (2026-10-23). There, the realm denylist is configurable, and the defaults block only loopback, link-local, unspecified and cloud metadata addresses, not RFC 1918.
• Helm's main already depends on oras-go v2.7.0, but no Helm release ships it yet (v4.3.1 is the latest).

Environment

• Flux v2.10.0, source-controller v1.10.1 (helm.sh/helm/v4 v4.3.1, oras.land/oras-go/v2 v2.6.4)
• DOKS 1.37, private DOCR, HelmRepository of type oci with a secretRef to the registry's dockerconfigjson pull secret

OCIRepository sources are not affected, since they don't go through oras-go. Neither are image pulls by the kubelet.

Request

Could source-controller bump oras.land/oras-go/v2 to v2.7.0 (or later) in a v1.10.x patch release, without waiting for the next Helm release? source-controller already pins oras-go directly in its go.mod.

Workaround

We pin api.digitalocean.com to its public IPs with hostAliases on the source-controller Deployment, through a kustomize patch in flux-system. It works, but it hardcodes third-party IPs. dnsPolicy: None with public resolvers is not an option, because source-controller needs cluster DNS for --events-addr.