Derive downloads.cdn.telerik.com for jobs holding a nuget.telerik.com credential

[recursor]

What are you trying to accomplish?

Fixes #306.

Hosted Dependabot nuget jobs on the licensed Telerik feed fail under proxy-egress-enforce. The feed (https://nuget.telerik.com/v3/index.json, declared in dependabot.yml as a nuget-feed registry with an api-key credential) authenticates fine and serves the service index, registration and package index, but answers every package download with a 302 to a pre-signed URL on https://downloads.cdn.telerik.com/.... The proxy refuses that second hop, and the updater reports it as private_source_authentication_failure:

proxy | GET https://downloads.cdn.telerik.com:443/<hash>_Telerik.Zip.2025.2.520.nupkg_4.0.0
proxy | * egress not allowlisted downloads.cdn.telerik.com
proxy | 403 https://downloads.cdn.telerik.com:443/<hash>_Telerik.Zip.2025.2.520.nupkg_4.0.0
updater | ERROR Error type: private_source_authentication_failure

Every licensed Telerik package (Telerik.UI.for.Blazor, Telerik.Documents.*, Telerik.Zip, the other UI suites) downloads through this CDN, so any repo on the Telerik feed hits it.

This adds downloads.cdn.telerik.com under registry_redirect_derivations, keyed on the credential host nuget.telerik.com.

Anything you want to highlight for special attention from reviewers?

Why registry_redirect_derivations and not the static nuget list. #306 asked for the static list, but the redirect is only reachable by a job that holds the feed credential (the feed is licensed; unauthenticated requests never get the 302). The derivation section opens the CDN only for those jobs, which is strictly tighter and equally sufficient, matching the add-egress-allowlist-domain guidance for the download target of a configured registry.

Why the exact form is safe. downloads.cdn.telerik.com is a single Progress/Telerik-owned host serving only their package artefacts, with no user-creatable names in it. The derived entry is matched exactly (the section rejects glob and leading-dot forms at startup), and the credential host is also exact, so evil.nuget.telerik.com or nuget.telerik.com.attacker.com in a credential derives nothing.

Ownership evidence. TLS: subject=CN=downloads.cdn.telerik.com, SAN downloads.cdn.telerik.com only, issuer=C=US, O=Amazon, CN=Amazon RSA 2048 M04; resolves to a public CloudFront address (3.168.70.234 at the time of writing). The redirect chain was reproduced with a real feed credential and --max-redirs 0:

GET https://nuget.telerik.com/v3/package/telerik.zip/2025.2.520/telerik.zip.2025.2.520.nupkg
status=302 next_hop=https://downloads.cdn.telerik.com/542ec0c3a7622c32cb2992fe37990abc_Telerik.Zip.2025.2.520.nupkg_4.0.0?<pre-signed query>

How will you know you've accomplished your goal?

Reproduction: the nuget in /. jobs of two private repos on the Telerik feed failed on every run with the log above; GitHub staff can pull the proxy log for INOV8Assist run 38601045294 (2026-10-14). Declaring https://downloads.cdn.telerik.com as a credential-less nuget-feed registry in dependabot.yml, which puts it in the job's dynamic hosts the same way this derivation does, made the next job finish without the error (INOV8Functions run 38285903239, 2026-10-12). This PR makes that per-repo workaround unnecessary.

Regression coverage:

• TestEgressDefaults_RegistryRedirectDerivationsLoadedFromYAML asserts the derivation for nuget.telerik.com.
• TestRegistryRedirectHosts_TelerikDownloadCDNDerived (egress_dynamic_hosts_test.go): a job with a nuget_feed credential for nuget.telerik.com reaches the feed and a realistic CDN download URL; evil.downloads.cdn.telerik.com, downloads.cdn.telerik.com.attacker.com, cdn.telerik.com, telerik.com and www.telerik.com stay blocked.
• TestRegistryRedirectHosts_TelerikMatchedExactly: only nuget.telerik.com (and its absolute-DNS form) derives the CDN; lookalike credential hosts derive nothing.
• TestRegistryRedirectHosts_TelerikCDNNotAllowedWithoutCredential: a job with a different nuget_feed credential cannot reach the CDN.

With the YAML entry removed, the first three tests fail; restored, go test -shuffle=on -count=2 ./... passes and gofmt -l internal/handlers/ prints nothing.

Checklist

• I have run the complete test suite to ensure all tests and linters pass. (go test -shuffle=on -count=2 ./... passes locally; script/test with -race could not run in my environment, no C compiler for cgo. Relying on CI for the race run.)
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

🤖 Generated with Claude Code