Skip to content

Bounding the redaction input hid throttle wording, so a deep-wording throttle is not retried at all #747

Description

@devops-thiago

Found by deep-audit round 7 against the shipped v0.6.4. Introduced by #740 (rework).

Cutting the body to 1024 characters before redaction also bounds what isThrottled() can see, because classification reads the log-shaped body. Throttle wording sitting behind more than ~1024 characters of credential-shaped material is therefore invisible, and the write is not retried at all — it fails fast, which is the pre-#495 behaviour this area exists to prevent. Threshold sweep from the audit:

prefix length v0.6.3 v0.6.4
900 chars throttled, PT30S throttled, PT30S
1010 chars throttled not throttled, PT5S

v0.6.3 was true at every size, because redaction ran over the whole body first.

This is adjacent to #732 but not the same bug: #732 is about the pre-existing 512-char cap and was equally true at v0.6.3, whereas this is the new bound on the redaction input, which closed the one path by which deep wording still survived. Both are fixed by the same change, so they should be done together.

Fix direction: classify on the collapsed body (bounded to a sane maximum) rather than on the log-shaped one, keeping the capped form for logging only.

Not reachable against api.github.com, whose error bodies are ~300 characters — it needs a large body from the configured API host.

Proof: audit report AUDIT7-B (finding B2).

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingreworkDefect introduced during this release cycle, not pre-existing

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions