fix(webhook): reject a non-ASCII signature header instead of crashing the endpoint

[Drexuxux]

What?

_validate_signature backs the public webhook receiver. It compared each attacker-supplied signature/token header (GitHub X-Hub-Signature-256, GitLab X-Gitlab-Token, generic X-Webhook-Signature/-V2, and the Svix v1 header) against a computed digest with hmac.compare_digest on two str values. compare_digest raises TypeError on a str containing non-ASCII characters, and the header is raw client input on an unauthenticated endpoint — so any internet client can POST a single non-ASCII byte in the signature header and raise out of the handler, returning a 500 instead of a clean 401. Fail-closed, but an on-demand crash of the request path.

Solution

Route all five comparisons through a small _hmac_str_equal() helper that encodes both sides to UTF-8 bytes before the constant-time compare (compare_digest has no ASCII restriction on bytes). Semantics are unchanged for valid signatures; a hostile non-ASCII header now fails closed with a rejection.

How to test

1. pytest tests/gateway/test_webhook_adapter.py::TestValidateSignature -q
2. New tests: non-ASCII GitHub/GitLab/generic/V2 signature headers return False (no raise); a non-ASCII configured secret still matches its exact token.
3. Re-run against pre-fix code to confirm they raise TypeError there.

Test results

• TestValidateSignature — 26 passed (23 existing + 3 new).
• Pre-fix, the 3 new tests fail with TypeError: comparing strings with non-ASCII characters is not supported; post-fix they reject / validate correctly.
• test_webhook_adapter.py + test_webhook_signature_rate_limit.py + test_msgraph_webhook.py — 120 passed, no regressions.

[teknium1]

Thanks for isolating the generic webhook fix and preserving constant-time comparison semantics. Current main still has the five direct str comparisons in gateway/platforms/webhook.py:930, :935, :978, :1002, and :1056; the PR replaces each one, and the handler's clean rejection path is at gateway/platforms/webhook.py:535-541.

Problems

• The same public-header pattern remains in gateway/platforms/whatsapp_cloud.py: it reads X-Hub-Signature-256 at :1464 and directly compares the derived string at :1512. That leaves the reported failure class in a sibling webhook endpoint.

Suggested changes

• Harden the WhatsApp Cloud path and add its non-ASCII rejection regression; audit the analogous authenticated string comparisons in gateway/platforms/msgraph_webhook.py:361 and gateway/platforms/api_server.py:1219.
• Add a Svix non-ASCII regression: this PR changes the Svix comparison, but the new tests do not enter that branch.

Automated hermes-sweeper review.

[teknium1]

This covers GitHub, GitLab, generic V1, and generic V2, but the patch also changes the Svix v1 comparison. Please add a non-ASCII svix-signature case with valid svix-id and timestamp so that branch is regression-tested too.

[teknium1]

Merged via PR #65697 (together with #65305) — your commits were cherry-picked onto current main with your authorship preserved in git log (rebase-merge), including the Svix v1 test coverage commit. We widened the fix to the remaining sibling compare_digest sites in a follow-up commit. Thanks!