acf7955f87
All checks were successful
ci/woodpecker/pr/ci Pipeline was successful
Round-9 auditor blockers, both fixed at root cause in the PyYAML-absent
line-parser fallback of get_gitea_token_for_login:
1. Control-character fail-open (dangerous): PyYAML 6.0.3's Reader rejects
the WHOLE document (ReaderError) if a forbidden C0/DEL control byte
{0x00-0x08, 0x0B, 0x0C, 0x0E-0x1F, 0x7F} appears ANYWHERE in the raw
stream -- plain scalar, inside quotes, or a comment -- regardless of
position, verified empirically against the real installed PyYAML 6.0.3.
The fallback previously only guarded tabs and emitted the login token
from such documents. Added a whole-document _FORBIDDEN_CONTROL scan on
the raw text (before splitlines(), which itself splits on some of the
same bytes) so the fallback fails closed identically to PyYAML.
2. Unsigned-exponent float over-rejection: PyYAML's implicit float
resolver requires an EXPLICIT sign on the exponent; unsigned-exponent
spellings (1.0e10, +1.0e10, -1.0e10, 1.0E10, .5e10, 4.e8) are PyYAML
STRINGS, not floats. The fallback's _IMPLICIT_FLOAT pattern allowed an
optional sign, misclassifying these as floats and dropping the token.
Tightened the regex to match PyYAML's resolver exactly.
Also folds in a residual over-rejection found via this round's wide
differential fuzz (1767 cases, 0 fail-opens / 0 over-rejections after the
fix): a plain scalar starting with "?" not followed by whitespace (e.g.
"?x") is a valid PyYAML string, but the fallback's blanket-reject set
treated every leading "?" as illegal. Narrowed to match the existing
space-aware handling already used for "-" and ":".
Adds regression fixtures to test-gitea-login-resolution.sh covering all
three fixes under both PyYAML-present and forced-ImportError-absent runs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>