Allow dotnetcli.blob.core.windows.net for .NET release metadata

[johanm76]

What are you trying to accomplish?

Dependabot nuget / .NET SDK update jobs need to read releases-index.json from https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json, but that host is not in the static egress allowlist, so the request is blocked under enforce.

This adds dotnetcli.blob.core.windows.net as an exact host to the dotnet_sdk ecosystem defaults in internal/handlers/egress_allowlist_defaults.yaml.

Why it belongs in the static defaults (public, provider-controlled infrastructure):

• Resolves to public Azure IPs under Microsoft's azuredns (azuredns-hostmaster.microsoft.com SOA).
• The real artifact path returns 200 anonymously (no auth challenge).
• TLS certificate is Microsoft's CN=*.blob.core.windows.net, O=Microsoft Corporation.
• Authoritative evidence: the official dotnet/core repo README documents this exact URL as Microsoft's production Azure Blob storage for .NET release metadata ("We use ... Azure Blob Storage as our production platform").

Anything you want to highlight for special attention from reviewers?

Matching form — exact host, deliberately not leading-dot/glob. blob.core.windows.net is a shared multi-tenant storage domain where the storage-account label is customer-choosable, so a .blob.core.windows.net or *…blob.core.windows.net form would be attacker-satisfiable. The exact host pins the globally-unique, Microsoft-owned dotnetcli account, which cannot be spoofed — the same reasoning used for the existing nugetregistryv2prod.blob.core.windows.net entry.

A negative child probe (https://evil.dotnetcli.blob.core.windows.net/payload) was added to TestEgressAllowlist_NewEntriesDoNotWidenBeyondExactHosts so that any future widening of this entry to a leading-dot suffix fails CI.

How will you know you've accomplished your goal?

• go build ./... — passes.
• go test ./internal/handlers/ -run TestEgress -count=1 — all egress tests pass, including TestEgressDefaults_NoRedundantEntries (not already covered) and TestEgressDefaults_AliasedEcosystemsStayInSync.
• Positive probe https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json is allowed.
• Mutation check: temporarily changing the entry to .dotnetcli.blob.core.windows.net makes the child probe fail (confirmed), then reverted.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• 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.

[Copilot]

Copilot review overview

🟢 Approval recommended

The narrowly scoped allowlist entry has authoritative ownership evidence and appropriate regression coverage.

Review effort: Balanced
Findings: None

What changed in this PR

Adds Microsoft’s exact .NET release-metadata host to the global egress defaults.

Changes:

• Allowlisted dotnetcli.blob.core.windows.net for dotnet_sdk.
• Added positive and exact-host boundary tests.

File	Description
internal/​handlers/​egress_allowlist_defaults.yaml	Adds the exact Microsoft-owned metadata host.
internal/​handlers/​egress_allowlist_test.go	Verifies access while blocking child subdomains.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[jurre]

Looks like Dependabot should be using https://builds.dotnet.microsoft.com/dotnet/release-metadata/releases-index.json for this instead as per dotnet/core#10262? That's already on the allowlist. I'm fine merging this as a stopgap, but should probably stop using this deprecated endpoint. cc @JamieMagee you might have more context here

[jurre]

It looks like this is actually an deprecated endpoint as per dotnet/core#10262 and we should be using this instead: https://builds.dotnet.microsoft.com/dotnet/release-metadata/releases-index.json, that's also already in the allow list. cc @JamieMagee you might have more context.

I'm fine merging this as a stop-gap until we have that fixed