mirror of
https://github.com/router-for-me/CLIProxyAPI.git
synced 2026-07-02 05:54:36 +08:00
53a21dfb0b
* Drop foreign encrypted_content before xAI Grok upstream xAI Grok accepts provider-native encrypted_content as opaque replay state, but GPT/Codex reasoning signatures, Gemini thoughtSignature blobs, and Claude thinking signatures can all travel through OpenAI Responses-style reasoning.encrypted_content while remaining incompatible with xAI. Forwarding those foreign blobs to Grok causes upstream validation failures, especially when the foreign value is high-entropy enough to look ciphertext-like. Add a Grok encrypted_content transport validator that stays conservative and shape-oriented: - require unpadded standard base64 with no foreign characters - reject obvious GPT/Codex gAAAA reasoning signatures before decode - reject strict Claude thinking signatures in both official E-form and Antigravity R-form - reject known Gemini thoughtSignature envelopes by reusing the central Gemini validator, covering Gemini 2.5 field-1 and Gemini 3.x field-2 shapes - require decoded payloads to be long enough and high-entropy enough to look like native Grok ciphertext - avoid decrypting, protobuf-parsing, or otherwise interpreting native Grok payloads on the hot path Wire the validator into the xAI Responses request preparation path for reasoning and compaction input items. Invalid encrypted_content fields are deleted before the request is sent upstream, while the surrounding item is preserved and debug logging records only redacted metadata. Extend coverage with native Grok corpus preservation, Gemini field-1/field-2 rejection, Claude E-form and R-form rejection, invalid-blob sanitizer tests, and compact/websocket replay preservation. The foreign-provider checks are deliberately narrow so high-entropy Grok blobs are not rejected merely because they look random. * fix(xai): harden encrypted content sanitizer