Problem
Recent hardening added non-TTY guards and an allow_from confirmation gate, but three adjacent gaps remain:
- Interactive channel login can hang forever.
raven channels login whatsapp in a real terminal starts the bridge and blocks until the QR is scanned or the process is killed; there is no timeout, no cancel hint, and no failure path if the user walks away. (Non-TTY invocations are now cleanly rejected with exit 2, but the interactive path is unbounded.)
raven channels set <name> --allow-from '*' silently opens a channel to anyone. The confirmation gate only runs on enable, so set is a quiet bypass of the enable-time gate.- Onboard's TTY check only inspects stdout.
raven onboard < /dev/null with a TTY stdout gets past the check and crashes inside questionary when the first prompt reads stdin. The shared guard already checks both directions; onboard should use it.
Evidence
- WhatsApp login blocks in raven/channels/adapters/whatsapp/bridge.py:91 ("blocks until it exits") behind raven/channels/adapters/whatsapp/channel.py:53; under a forced non-interactive harness the wait had to be killed externally (observed exit 142 via an alarm). The non-TTY guard sits at raven/cli/channel_commands.py:539.
_gate_open_allow_from (raven/cli/channel_commands.py:118) is called exactly once, from the enable path at raven/cli/channel_commands.py:288; the set command registered at raven/cli/channel_commands.py:322 never calls it.- raven/cli/onboard_commands.py:328 checks
sys.stdout.isatty() alone; raven/cli/_tty_guard.py:6 describes itself as "onboard's _check_tty_or_die, plus the stdin check it lacks".
Suggested direction
- Wrap the interactive login wait with a timeout plus a printed cancel hint (Ctrl-C handling that cleans up the bridge process), or at minimum a periodic "still waiting for QR scan" line.
- Route set through the same
_gate_open_allow_from confirmation used by enable (or at least print the same warning).
- Switch onboard's
_check_tty_or_die to the shared die_if_not_tty guard so stdin is covered.
Problem
Recent hardening added non-TTY guards and an allow_from confirmation gate, but three adjacent gaps remain:
raven channels login whatsappin a real terminal starts the bridge and blocks until the QR is scanned or the process is killed; there is no timeout, no cancel hint, and no failure path if the user walks away. (Non-TTY invocations are now cleanly rejected with exit 2, but the interactive path is unbounded.)raven channels set <name> --allow-from '*'silently opens a channel to anyone. The confirmation gate only runs on enable, so set is a quiet bypass of the enable-time gate.raven onboard < /dev/nullwith a TTY stdout gets past the check and crashes inside questionary when the first prompt reads stdin. The shared guard already checks both directions; onboard should use it.Evidence
_gate_open_allow_from(raven/cli/channel_commands.py:118) is called exactly once, from the enable path at raven/cli/channel_commands.py:288; the set command registered at raven/cli/channel_commands.py:322 never calls it.sys.stdout.isatty()alone; raven/cli/_tty_guard.py:6 describes itself as "onboard's _check_tty_or_die, plus the stdin check it lacks".Suggested direction
_gate_open_allow_fromconfirmation used by enable (or at least print the same warning)._check_tty_or_dieto the shareddie_if_not_ttyguard so stdin is covered.