mirror of https://github.com/kuhyx/signal-bot.git synced 2026-11-11 14:37:32 +01:00

Krzysztof kuhy Rudnicki 6bde3493a4 feat: rewrite the bot so it runs, and gate it like the other repos

The bot did not work. `run.sh` started a FastAPI app whose
`@app.on_event("startup")` awaited `asyncio.gather()` on two infinite
tasks, so uvicorn never finished starting up and no HTTP was ever served;
the readme's `python main.py` was a no-op with no `__main__` block and no
`uvicorn.run()` call. All three CI workflows were red, one referencing an
`environment.yml` that does not exist.

Rewritten as a package behind an injectable transport seam, which is what
makes the offline environment possible.

Bugs fixed:
- startup deadlock: lifespan spawns the loops instead of awaiting them
- sticker filter read dataMessage.sticker even on syncMessage envelopes, so
  the account's own stickers were never filtered (e038772, 53028cc, 07fa90d,
  2416cef all fought this symptom)
- no websocket reconnect: a container restart killed the bot silently
- blocking `requests` inside async functions stalled the event loop
- every counted message DMed the whole tally to the bot itself
- images were written to CWD under a filename taken from the remote URL
- one global 10s cooldown shared across all users and commands
- dead code: RECEIVE_URL, get_attachments (no call site), USER_MESSAGE_COUNT
- .env.sample declared PRIMARY/SECONDARY_PHONE_NUMBER and MODE, none read

Scoping is now an enforced invariant. A linked device receives every DM and
every group on the account; GROUP_ID was the only thing narrowing that and
defaulted to "". Config refuses to start unscoped, direct messages are
dropped explicitly rather than by a falsy check, and a scenario asserts that
DMs and other groups produce zero outbound messages.

Offline environment: fake_signal/ serves the real protocol surface, so the
unmodified bot connects to it by pointing API_BASE_URL at it. scripts/e2e.sh
boots both, replays 7 scenarios and exits non-zero on mismatch. A local
Signal server is not achievable (signal-cli compiles its endpoints and trust
store in; Signal-Server needs FoundationDB), so faking this boundary is the
only way to test every feature without an account.

Transport pinned to bbernhard/signal-cli-rest-api:0.100 with
MODE=json-rpc-native. The readme pinned 0.167-dev; the dev tag series counts
separately, so that was older than 0.100, not newer. /v1/receive is only a
WebSocket in a json-rpc mode, so the mode is verified at startup.

Repo standards: ruff select=ALL, mypy --strict, 189 tests at 100% branch
coverage, 250-line cap, exact pins at newest stable, shared gates delegated
to ~/utils, one CI workflow replacing three red ones. No noqa, no
type: ignore, no coverage omits anywhere.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013yaBT45KhHqxTKVCTA87iy

2026-08-29 13:05:42 +02:00

1.5 KiB

Raw Blame History

Security Policy

Scope of a linked device

This bot runs as a linked device on an existing Signal account. That means it can read every direct message and every group on that account, and anything it sends is sent as the account owner. It is not a separate identity.

GROUP_ID is the only thing that narrows this. The bot therefore:

refuses to start when GROUP_ID or GROUP_ID_SEND is missing or blank, rather than defaulting to an empty string that matches nothing predictably;
drops messages with no groupInfo (direct messages) explicitly, in counting.is_watched_group, rather than relying on a falsy comparison;
ships a scoping scenario asserting that direct messages and other groups produce zero outbound messages, run by scripts/e2e.sh in CI.

If you widen that boundary, the scoping scenario is what should fail.

Secrets

.env is gitignored and never committed. .env.sample contains no real values. The bot reads no credentials of its own: authentication is the signal-cli data directory mounted into the container, which stays on the host.

Reporting a vulnerability

Open an issue at https://github.com/kuhyx/signal-bot/issues. If the issue would expose message content or account access, say so without a working proof of concept in the public issue.

Dependencies

Every dependency is exact-pinned at its newest stable release and checked by scripts/check_dependency_freshness.sh in pre-commit and CI. There are no pre-release pins.