fix: close remaining critical SSRF alerts

[KDB-Wind]

概要

• 对 LightRAG 配置型 base URL 增加 URI/OkHttp canonical host 一致性校验，使既有固定 authority 边界可被 CodeQL 识别
• 升级普通 CI / integration / supply-chain 的 setup-java 到 v5、setup-node 到 v6，消除已知 Node 20 运行时弃用项

验证

• LightRagClientTest：7/7 通过
• 等待 PR CodeQL 确认默认分支告警 fix(frontend): clear lint issues and enforce lint gate #6/feat(ci): add dependabot, codeql and dependency review gates #7 不再出现

此 PR 不自动合并。

[KDB-Wind]

/deepseek-review

[github-actions]

PR #11 第一层审查（只读，COMMENTED）

结论：未发现 P0/P1 阻塞问题。 3 个 P2，集中在 LightRagClient.parseBaseUrl 的兼容性与测试缺口；CI workflow 变更（setup-java v5.7.0 / setup-node v6.0.0 均带 SHA pin + tag 注释，权限与并发模型未变）未发现问题。

---

P2-1 新 host 一致性校验误拒合法 IPv6 / IDN base URL（行为回归）

• 文件/行号：bootstrap/.../rag/core/graph/LightRagClient.java:322
• 影响：合法配置启动即抛 IllegalArgumentException，应用无法启动。
• 证据：candidate.host() 来自 OkHttp，IPv6 地址不带方括号（::1）；而 java.net.URI.getHost() 对 IPv6 保留方括号（[::1]）。二者等值比较恒为 false → http://[::1]:9621 这类本可通过 HttpUrl.parse 的地址被判定"主机格式不安全"。IDN 域名同理：OkHttp 会归一化为 punycode（xn--…），URI 保留原始字符，同样恒不等而被误拒。默认配置 http://127.0.0.1:9621（GraphProperties.java:68）不受影响，所以现有测试测不出。
• 最小修复：比较前归一化，如去掉方括号后再比：

  String hostA = candidate.host();
  String hostB = canonicalUri.getHost();
  boolean same = hostB != null && stripBrackets(hostA).equals(stripBrackets(hostB));
  if (!same) throw ...

  或在注释中明确"仅支持域名/IPv4"，并在文档标注 IPv6 不可用。

P2-2 新增校验分支完全无测试覆盖，回归无法被发现

• 文件/行号：bootstrap/src/test/.../LightRagClientTest.java:164-176
• 影响：P2-1 即由该缺口掩盖；后续改动（如 path 归一化、安全 URL 重建）同样无回归防线。
• 证据：invalidBaseUrlFailsFast 只覆盖 file:// 与 user-info 两个分支；query、fragment、host 一致性（:322）、safeUrl == null（:326）、尾斜杠归一化（:329-330）均无用例，也没有"合法 IPv6/IDN base URL 应通过"的正向用例。
• 最小修复：补 assertDoesNotThrow 用例（http://[::1]:9621、IDN 域名）+ 拒绝用例（http://x/?q=1、http://x/#f、http://foo_bar.com 等），并断言归一化后 path 以 / 结尾。

P2-3 该校验不构成实际 SSRF 防线，信任边界需写明

• 文件/行号：LightRagClient.java:311-331；相关 SSRF 面见 url() :303-309 与 fetchGraph/fetchLabels :122-173
• 影响：PR 描述称"关闭剩余 critical SSRF 告警"，但一致性校验只保证两个解析器意见一致，两者可一致地接受 http://169.254.169.254 等内网/元数据地址。当前安全性实际依赖三条既有约束：baseUrl 仅来自管理员配置、所有 path 为编译期常量、用户输入（label/keyword）经 HttpUrl.Builder.addQueryParameter 百分号编码且被测试锁定（graphLabelCannotChangeConfiguredAuthority）。这三条一旦被后续重构破坏（如引入动态 path），本校验不会兜底。
• 最小修复：在校验处加注释明确信任边界（"配置信任 + path 常量 + query 编码"是实际防线），不必改动逻辑；若需求要求阻断内网目标，则需显式 allowlist/blocklist（如拒绝 loopback、link-local、云元数据段）而非双解析器一致性。

---

其余核对（未发现问题的项）：retrieveByScope/deleteMatching 逻辑未变；baseUrl final、无新增共享状态（并发无风险）；无新增凭据读写路径，user-info 拒绝反而消除了 URL 内嵌凭据泄露面；CI 三个 workflow 的 action 升级仅为版本号变更，npm ci/npm run sbom 等在 setup-node v6 下行为兼容（node-version 仍显式 20.19.0）。注：无法在线核对 SHA（b6effb05… / 2028fbc5…）是否确为 v5.7.0 / v6.0.0 发布 tag，合入前建议人工核对一次。

github run

[KDB-Wind]

已处理 DeepSeek 的 3 条 P2：验证确认 Java URI 对 IPv6 返回带方括号 host，现已归一化后比较；补齐 IPv6/IDN 正向与 query/fragment 负向测试（LightRagClientTest 8/8）；并在代码中明确管理员配置 + 常量 path + query 编码才是实际信任边界，双解析一致性不等同私网 allowlist。修复提交：1585676。

[KDB-Wind]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Swish!

Reviewed commit: 1585676959

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".