[mr-kelly]

Verification level: 🟡 Partially verified. Every CI job was reproduced locally on this branch, and the fork's Redis self-signed TLS change was exercised against a real TLS Redis. Not covered: Bedrock compat routing against real AWS Bedrock (unit tests only).

Problem

Every PR on this fork fails backend-security and frontend-security. The fork is 7,786 commits behind upstream Wei-Shaw/sub2api and still on Go 1.26.3 with golang.org/x/net v0.53.0. govulncheck reports 22 reachable vulnerabilities, and pnpm audit reports 20+ high-severity advisories with no exceptions (plus two xlsx exceptions that expired on 2026-07-06). Upstream has already fixed these (Go 1.27.3, x/net v0.62.0).

Fix

Merge upstream/main into main and keep the fork's two own commits. Neither of them exists upstream:

• chore: sync main with upstream Wei-Shaw/sub2api #2 Self-signed Redis TLS. Kept TLSSkipVerify next to upstream's new Redis Username in setup/handler.go, setup/setup.go, the config and docker-compose.dev.yml. Upstream still renders a Redis TLS toggle inside the database step of the setup wizard; chore: sync main with upstream Wei-Shaw/sub2api #2 removed it, and it stays removed. The tlsSkipVerify strings moved into the new split i18n files (locales/{en,zh}/landing.ts), because upstream deleted en.ts/zh.ts.
• feat(payment): 新增 Creem 支付接入 #3 Bedrock compat routing. The text merge compiled cleanly, but upstream had changed the APIs underneath it. Ported to the new signatures:
  • PrepareBedrockRequestBodyWithTokens gained a ccCompat flag. It is passed as false, the same as upstream's own Bedrock path, because compat-endpoint bodies are generated by the converter, not sent by Claude Code.
  • handleCCStreamingFromAnthropic lost its includeUsage argument.
  • The Responses handlers now require clientToolMapping.
  • Reasoning effort was computed twice (:= redeclared). The Bedrock branch now bills it the same way as upstream's main path, from output_config.effort of the converted body.

Update: vue-i18n security fix (2nd commit)

After this PR was opened, GHSA-83rm-6c8r-g728 (vue-i18n) was published and failed frontend-security. vue-i18n 9.x has no patched release, so vue-i18n and @intlify/message-compiler are upgraded to 11.4.14, the same fix as vikadata/moonrouter#52. Node is now >= 22 and CI runs on Node 24. SubscriptionPlanCard.spec.ts is updated for vue-i18n 11's test behaviour.

• pnpm audit gate: "Audit exceptions validated."; full vitest 375 files / 3,011 tests pass; eslint and vue-tsc pass.
• Real browser on a running instance, zh and en: dashboard, batch-image (including the <i18n-t> usage guide), purchase and admin settings all render translated text, with no raw keys and no page errors.
• CI: backend-security and frontend-security are now ✅. cla-check still fails because this fork has no cla-signatures branch; that is a repository-config issue, not code.

Validation

Method: every CI job reproduced locally on this branch with the CI tool versions, plus real-service checks.

Check	Result
govulncheck ./... (security-scan)	✅ 0 vulnerabilities affecting the code (was 22)
pnpm audit + tools/check_pnpm_audit_exceptions.py (security-scan)	✅ "Audit exceptions validated."
pnpm install --frozen-lockfile (pnpm 9, as in CI)	✅
golangci-lint v2.14.0 (CI version)	✅ 0 issues
go test -tags=integration ./...	✅ pass
go test -tags=unit ./...	✅ pass, with one test failing only under local load: TestValidateCreateParams_CheckModeMatrix/probe_requires_api_key hit a 5s local DNS timeout. It passes 3/3 when run alone, the files are identical to upstream, and it also passes alone on pure upstream/main.
Frontend lint:check, vue-tsc, critical vitest (make test-frontend)	✅ 30 files / 576 tests
Full vitest	✅ 375 files / 3,011 tests (the 13 failures seen on the old fork are fixed upstream)
deploy script tests	⚠️ apple-container-test.sh fails locally with stat: cannot read file system information for '%Lp'. It fails identically on pure upstream/main, so it is local-environment only (GNU vs BSD stat).
Fork #3 TestGatewayService_ForwardAs{ChatCompletions,Responses}_BedrockAPIKeyUsesBedrockRuntime	✅ pass

Real Redis with a self-signed TLS certificate (openssl s_client: "Verify return code: 18 (self-signed certificate)"):

Path	Result
Setup wizard POST /setup/test-redis, tls_skip_verify=true	✅ "Connection successful"
… tls_skip_verify=false	✅ rejected: x509: cannot validate certificate
… TLS off against the TLS-only port	✅ rejected (EOF)
Runtime: AUTO_SETUP with REDIS_ENABLE_TLS=true REDIS_TLS_SKIP_VERIFY=true	✅ server started, /health 200, config.yaml has enable_tls: true and tls_skip_verify: true, and the app wrote 229 keys to the TLS Redis

Known risks / not covered

• Bedrock compat routing (feat(payment): 新增 Creem 支付接入 #3) was not run against real AWS Bedrock. Only its unit tests were run.
• This is a large upstream jump (0.1.x → 0.2.19, 3,518 files). Upstream behaviour changes come along with it; review the upstream changelog before deploying.
• cla-check will still fail until the fork's CLA workflow has a cla-signatures branch, or until the workflow is removed for this internal fork. This commit's author email is the GitHub noreply address of mr-kelly, so the bot can at least identify the signer.

Screenshots

Story: an operator installs Sub2API against a Redis with a self-signed TLS certificate

1. Database step: the misplaced Redis TLS toggle is gone (chore: sync main with upstream Wei-Shaw/sub2api #2's fix kept)
   
2. Redis step: upstream's new Username field and the fork's "skip certificate verification" toggle both appear; the test connection to the self-signed TLS Redis succeeds
   

After merging

The Creem PR #1 will be rebased onto the new main and re-verified, because upstream reworked the payment UI.

🤖 Generated with Claude Code

[github-actions]

Thank you for your contribution! Before we can merge this PR, we need you all to sign our Contributor License Agreement (CLA).

To sign, please reply with the following comment:

I have read the CLA Document and I hereby sign the CLA

You only need to sign once — it will be valid for all your future contributions to this project.

---

I have read the CLA Document and I hereby sign the CLA

---

0 out of 15 committers have signed the CLA.
❌ @SavitarC
❌ @Wei-Shaw
❌ @IrisRainbowNeko
❌ @feeeei
❌ @wucm667
❌ @ouchihao
❌ @ShuminFu
❌ @hutututtt
❌ @obst4cle
❌ @Yukinoshita-Yukino
❌ @Larry-Labs
❌ @xcrong
❌ @SipengXie2024
❌ @baryon
❌ @coder-zhw
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}