[hoshi-vo]

What are you trying to accomplish?

Hosted Dependabot swift version updates fail with proxy-egress-enforce for any repo that depends on the Pangle iOS SDK through SwiftPM, for example via Google's Pangle mediation adapter. The adapter depends on bytedance/AdsGlobalPackage. Its Package.swift declares the PAGAdSDK and TikTokBusinessSDK SwiftPM binaryTargets on https://sf16-fe-tos-sg.i18n-pglstatp.com/..., and the proxy returns 403 for that host:

GET https://sf16-fe-tos-sg.i18n-pglstatp.com:443/obj/pangle-sdk-static-va/8.3.0.8/PAGAdSDK.xcframework.zip
* egress not allowlisted sf16-fe-tos-sg.i18n-pglstatp.com
403 https://sf16-fe-tos-sg.i18n-pglstatp.com:443/obj/pangle-sdk-static-va/8.3.0.8/PAGAdSDK.xcframework.zip

SwiftPM resolves the whole package graph while Dependabot parses the manifest, so the job fails in Dependabot::Swift::FileParser and no Swift update PRs are opened at all. Ignoring the dependency in dependabot.yml does not help.

The host is Pangle's (ByteDance) SDK CDN. It is referenced from the vendor's own public Package.swift and serves the artifacts anonymously, so there is no credential to declare under registries:.

This PR adds sf16-fe-tos-sg.i18n-pglstatp.com as an exact host to ecosystem_default_domains.swift.

Fixes #315

Anything you want to highlight for special attention from reviewers?

One exact entry is enough. Probing the artifact path from the failing job with --max-redirs 0 returns 206 with an empty redirect_url, and an anonymous HEAD returns 200 application/zip. The host is a CNAME to Akamai (sf16-fe-tos-sg.i18n-pglstatp.com.edgesuite.net → a1818.mm2.akamai.net), and every address it resolves to is public.

Ownership evidence. Certificate Transparency logs show the certificate is a DigiCert RapidSSL DV wildcard for *.i18n-pglstatp.com, so it carries no organisation name. As with sdk.karte.io, the evidence comes from the vendor's own manifests:

• The chain runs from Google's public adapter manifest to bytedance/AdsGlobalPackage to this host.
• The same host is used across releases (8.2.1-release.1, 8.3.0-release.8).
• Responses carry ByteDance's own infrastructure headers (X-Tos-Request-Id, x-tt-trace-id, X-TT-LOGID).

About the path-style /obj/<bucket>/ layout. The bucket name is in the path, which is the shape the allowlist skill flags for multi-tenant hosts. I think the exact entry is still safe because the hostname belongs to ByteDance's own Pangle static domain (i18n-pglstatp.com), not to a public object-storage endpoint that arbitrary customers can publish to. The buckets reachable through it are therefore ByteDance-controlled. If you'd prefer a different shape, I'm happy to change it.

Exact, deliberately. The certificate is a wildcard over *.i18n-pglstatp.com, so the parent namespace stays closed and only the one CDN host named in the manifest is added.

swift is not an anchor/alias member, so no aliased ecosystem needs the same edit. Precedents for this section: #290 / #298 (sdk.karte.io) and #304 / #305 (prelude-public.s3.amazonaws.com).

How will you know you've accomplished your goal?

Reproduction (proxy 4f831d2, 2026-10-14): under enforcement, both the PAGAdSDK and TikTokBusinessSDK requests return 403 and the Swift job fails:

error: failed downloading 'https://sf16-fe-tos-sg.i18n-pglstatp.com/obj/pangle-sdk-static-va/8.3.0.8/PAGAdSDK.xcframework.zip' which is required by binary target 'PAGAdSDK': badResponseStatusCode(403)
error: failed downloading 'https://sf16-fe-tos-sg.i18n-pglstatp.com/obj/pangle-sdk-static-va/8.3.0.8/TikTokBusinessSDK.xcframework.zip' which is required by binary target 'TikTokBusinessSDK': badResponseStatusCode(403)

Other binary targets in the same job (dl.google.com, GitHub release assets, sdk.karte.io) download successfully.

Coverage in TestEgressAllowlist_PublicVendorRegistriesAllowed:

• Positive: both exact URLs from the failing job.
• Negative child: https://evil.sf16-fe-tos-sg.i18n-pglstatp.com/payload. I confirmed it bites by temporarily changing the entry to .sf16-fe-tos-sg.i18n-pglstatp.com. The test failed with must stay blocked: https://evil.sf16-fe-tos-sg.i18n-pglstatp.com/payload, and I then reverted the change.
• Negative sibling and parent: https://attacker.i18n-pglstatp.com/payload and https://i18n-pglstatp.com/payload. Changing the entry to .i18n-pglstatp.com makes all three negative probes fail.

Ran locally with Go 1.27.2: go build ./..., go test ./internal/handlers/ -run TestEgress -count=1, gofmt -l internal/handlers/ (empty output) and go test -race -shuffle=on -count=2 ./... (all packages pass). The Docker daemon wasn't available, so I didn't run script/test itself, and that box is left unticked.

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.

🤖 Generated with Claude Code