Originally created by: fu351
Originally owned by: atiqur-rahman-pro
_challenge_message in src/doberman/auth/provider.py builds the text a human reads to approve or deny a live action. Lines 81-82 contain two non-ASCII characters:
-> is currently the arrow U+2192 in the action lineU+2014CLI output in this repo is pure ASCII by contract (branding.py: "pure ASCII (enforced by tests)") because non-cp1252 characters crashed onboarding on legacy Windows consoles once before (PR [#54]). This string reaches all three prompters (CliPrompter, TtyPrompter, GuiPrompter), and it is the highest-stakes text in the app: the approval prompt itself. An earlier fix cleaned the same character class out of 2fa remove and locked it with a test - this is the same bug in a file no ASCII test covers.
-> and the em-dash with - in _challenge_message (a two-character diff).Decision/SecurityObject fixture, call _challenge_message, and assert .encode("ascii") does not raise. Follow the sibling pattern in tests/unit/test_cli_encode_safe.py (or extend tests/unit/test_auth_provider.py).One function, an existing test pattern to copy, no behavior change beyond the two characters. Found by the 2026-08-11 UX re-audit.
Originally posted by: atiqur-rahman-pro
Hi @fu351,
I would like to take this on!
I will replace the non-ASCII arrow (
→->->) and em-dash (—->-) in_challenge_messageinsidesrc/doberman/auth/provider.pyand add the ASCII-encodable assertion test intests/unit/test_auth_provider.py.Could you please assign this issue to me? thank you.
Ticket changed by: fu351