fix(providers): allow canonical Antigravity through fake-IP save validation

[juzijia]

Summary

• Allow config-write DNS validation to treat 198.18.0.0/15 as transparent Fake-IP only for the exact canonical Google Antigravity transport (google-antigravity + google adapter + OAuth + the registry daily-cloudcode-pa.googleapis.com base URL).
• Keep overridden Antigravity base URLs, wrong adapter/auth shapes, literal benchmark IPs, RFC1918/loopback/metadata answers, and mixed benchmark + private/metadata answer sets fail-closed.
• Centralize the exception in providerDestinationResolvedError, so the existing management write/reload callers get the same bounded behavior without enabling allowPrivateNetwork or weakening runtime URL fetch policy.

Verification

• Audited the branch diff against upstream dev (45cfb04e9757a5a257ab6290d9f24d2ea0bc7573): only src/lib/destination-policy.ts and tests/routing/destination-policy-resolved.test.ts change.
• Added focused regression coverage for the reported daily-cloudcode-pa.googleapis.com -> 198.18.1.68 case plus negative coverage for custom base URL, adapter/auth mismatch, literal benchmark destination, RFC1918 companion, and metadata companion.
• Performed a static TypeScript audit of the new test literals and corrected tuple inference before opening this PR.
• Repository Bun tests and full typecheck were not run in this connector-only environment; this PR is opened as draft so CI/maintainer verification can remain authoritative before review-ready status.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed. No new setting or public contract is introduced; this restores the existing bounded Fake-IP behavior for the canonical Antigravity save path.
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults. The patch is intentionally fail-closed outside the exact registry transport; maintainer security review is requested before marking ready.

Review readiness checklist

This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:

• All CI tests are green on my local testing.

• I pushed my PR to the latest dev commit.

• I resolved all correct Codex and CodeRabbit findings.

• My PR is ready for review.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

✅ Deterministic PR hygiene checks passed.

[github-actions]

⏳ DRAFT

• review readiness checklist open (0/4 boxes ticked).

What to do

• Tick all four boxes in the PR description once you're done (currently 0/4).

Review readiness checklist

• ⬜ All CI tests are green on my local testing.
• ⬜ I pushed my PR to the latest dev commit.
• ⬜ I resolved all correct Codex and CodeRabbit findings.
• ⬜ My PR is ready for review.

0/4 boxes ticked.

This PR stays in draft until every box above is ticked.

[lidge-jun]

리뷰 · 우선순위 74 / 80

이 PR은 지금 dev 끝(45cfb04e9, 패키지 2.57.0)에서 설정 저장·리로드 때 쓰는 DNS SSRF 검사 providerDestinationResolvedError에, 레지스트리 시드와 완전히 같은 Google Antigravity 전송만 Clash/Mihomo Fake-IP(198.18.0.0/15) DNS 답을 허용하는 예외를 넣습니다. 지금 dev에는 ChatGPT Codex(openai 정본 시드)만 관리 API 쪽에서 allowBenchmarkAddresses: true를 넘기도록 되어 있고(src/server/management/provider-routes.ts의 isCanonicalOpenAiForwardProvider), Antigravity는 같은 Fake-IP DNS를 받아도 저장이 막힙니다. 현장에서는 daily-cloudcode-pa.googleapis.com -> 198.18.x처럼 투명 DNS가 흔해서, 프록시는 실제로 쓸 수 있는데 관리 UI/설정 쓰기만 거절되는 불일치가 납니다.

고치는 방식은 openai처럼 라우트마다 플래그를 더 넣는 대신, src/lib/destination-policy.ts 안에 registryAllowsBenchmarkDnsAtWriteTime을 두고 providerDestinationResolvedError가 호출자 옵션과 OR로 예외를 켭니다. 조건은 좁습니다. 이름 google-antigravity, 레지스트리 authKind === oauth + allowBaseUrlOverride, 호출 쪽 adapter/authMode이 시드와 같고, baseUrl이 정규화 후 시드 URL(https://daily-cloudcode-pa.googleapis.com)과 같을 때만입니다. 커스텀 릴레이 URL, 어댑터/인증 불일치, 리터럴 198.18 URL, 벤치마크+사설/메타데이터 혼합 답은 계속 막습니다. allowPrivateNetwork를 키우거나 런타임 resolvePublicAddresses 기본값을 느슨하게 만들지 않습니다. 테스트도 같은 파일에 긍정 1개·부정(커스텀/어댑터/키/혼합/리터럴)을 같이 넣었습니다. 범위는 destination-policy.ts + 해당 테스트뿐이라 types/config 분할 캠페인과도 안 겹칩니다.

왜 점수 74인가. 현장 Fake-IP 저장 거절을 정본 전송에만 풀어 주는 방향이 맞고, 실패 닫힘(fail-closed) 부정 테스트가 분명합니다. 다만 openai는 아직도 관리 라우트가 명시적으로 플래그를 넘기고 Antigravity만 정책 함수 안으로 예외가 들어가서 패턴이 갈라집니다. 또 예외는 adapter/authMode가 호출 객체에 실려 와야 켜지므로, baseUrl만 넘기는 호출 경로는 의도적으로 예외 밖입니다(안전에는 이득). draft + 로컬 스위트 미실행이라 CI가 권위입니다. Mihomo IPv6 Fake-IP(fdfe:dcba:9876::/48)는 이 PR 범위 밖입니다.

src/lib/destination-policy.ts registryAllowsBenchmarkDnsAtWriteTime - 예외가 켜지려면 호출자가 adapter/authMode를 같이 넘겨야 한다. 관리 저장·리로드가 디스크/에디터 전체 row를 넘기면 동작하고, baseUrl만 넘기는 경로에서는 예외가 안 켜진다(문서/호출 계약 확인 필요).
src/lib/destination-policy.ts providerDestinationResolvedError - openai는 provider-routes.ts에서 allowBenchmarkAddresses를 넘기고, Antigravity는 정책 함수 내부 OR로 켠다. 같은 Fake-IP 예외인데 진입점이 두 갈래라 이후 제공자 추가 때 어디에 넣을지 헷갈릴 수 있다.
src/lib/destination-policy.ts EOF - 파일 끝 개행이 빠졌다(diff No newline at end of file). 작은 스타일/도구 소음.
tests/routing/destination-policy-resolved.test.ts Antigravity describe - 정규화(끝 슬래시·대소문자 호스트) 긍정 케이스는 없고, IPv6 Mihomo Fake-IP는 다루지 않는다. 이번 현장 리포트가 IPv4 198.18.1.68이면 충분하지만 범위 한계는 적어 두는 편이 좋다.
src/server/management/provider-routes.ts (이 PR 밖) - openai용 name === "openai" && isCanonicalOpenAiForwardProvider 자리는 그대로다. Antigravity를 같은 자리에 대칭으로 넣을지, 이번처럼 정책 쪽으로 모을지 한쪽으로 정리하는 편이 유지보수에 낫다.

메인테이너의 판단이 필요한 지점

• Fake-IP 예외를 openai처럼 관리 라우트 호출부에 둘지, 이번 PR처럼 destination-policy 레지스트리 검사로 모을지.
• draft 체크리스트·보안 리뷰를 통과시키기 전에 ready로 올릴지(작성자도 보안 리뷰를 요청함).
• IPv6 Mihomo Fake-IP까지 같은 정본 Antigravity에 허용할지, 이번엔 IPv4만으로 닫을지.

너의 추천
draft 유지. 호스트 CI에서 destination-policy-resolved 관련 테스트가 초록이면, 정책 쪽 중앙화 방향을 메인테이너가 OK한 뒤 merge. squash보다 커밋 그대로(또는 작은 EOF 개행만 정리) 권장. types/config 분할과 무관하니 close-don't-rebase 대상 아님. 관련 이슈 번호가 본문에 없으면 현장 재현 이슈를 Fixes #로 묶으면 추적에 좋다.

이 댓글은 grok-bot이 작성했습니다