Redact phone numbers and webhook details from default logs

[Justinabox]

Summary

Several default INFO/WARNING log paths include phone numbers, webhook URLs, or raw modem response lines. In server.py, the process enables INFO logging by default, so a normal HTTP/server deployment can write caller/SMS metadata to logs even though the project north-star explicitly calls for "no secrets in logs" and PII-safe operations.

This is a production-readiness/security gap for unattended Pi deployments used for MFA/SMS automation: logs are commonly shipped, copied into bug reports, or exposed to service managers.

Evidence

Baseline is healthy:

$ git diff --check
# exit 0

$ PYTHONPATH=. uv run --no-project --with pytest --with pytest-asyncio --with pytest-aiohttp --with pyserial-asyncio --with aiosqlite pytest tests/ -q
361 passed in 4.23s

Minimal repro for SMSService.send at INFO level using a fake executor:

$ PYTHONPATH=. uv run --no-project --with pyserial-asyncio python - <<'PY'
import asyncio, logging
from callstack.sms.service import SMSService
from callstack.events.bus import EventBus
from callstack.protocol.executor import ATResponse

class FakeAT:
    async def execute(self, command, **kwargs):
        return ATResponse(success=True, lines=['>'] if command.startswith('AT+CMGS') else ['OK'])
    async def send_data(self, data, **kwargs):
        return ATResponse(success=True, lines=['+CMGS: 7', 'OK'])

async def main():
    logging.basicConfig(level=logging.INFO, format='%(name)s %(levelname)s %(message)s')
    svc = SMSService(FakeAT(), EventBus())
    await svc.send('+155****4567', 'hello')

asyncio.run(main())
PY
callstack.sms INFO SMS sent to +155****4567 (ref: 7)

The number above is a fake masked placeholder, but the code logs the real to value in production.

Static inspection found additional PII-adjacent log paths:

• server.py:268-270 sets default server logging to INFO.
• server.py:217-219 logs webhook POST URLs on failures.
• server.py:227-229 logs session.number for incoming calls.
• callstack/sms/service.py:172-173 logs outbound SMS recipient.
• callstack/sms/service.py:199-201 logs inbound SMS sender.
• callstack/voice/service.py:69-70, :93-94, and :165-166 log dial/caller numbers.
• callstack/modem.py:168-179, callstack/voice/service.py:148-149, and callstack/protocol/urc.py:70-71 can log raw response/URC/exception text, which may contain modem identifiers or message fragments depending on failure mode.

Expected behavior

Default logs should be safe to attach to support issues or ship to system logging without exposing real phone numbers, SIM identifiers, SMS bodies/passcodes, webhook URLs, or raw modem payloads.

Suggested fix direction

1. Add a small redaction helper for phone-like strings, URLs with tokens/query strings, SMS bodies/passcode-looking fields, and raw AT response lines.
2. Use structured fields where possible and log redacted values by default, e.g. last-2/last-4 only or stable hashes when correlation is needed.
3. Keep verbose raw AT/URC dumps behind an explicit unsafe debug flag if needed for hardware troubleshooting.
4. Add tests with fake sensitive-looking strings in logs and assert caplog.text excludes the raw values.

Acceptance criteria

• Default INFO/WARNING/ERROR logs do not include full phone numbers, SMS bodies/passcodes, webhook URLs, SIM/IMEI-like identifiers, or raw modem response lines containing those values.
• Existing CLI tests that assert private SMS fields are not printed continue to pass.
• New caplog tests cover SMS send/receive, voice caller/dial logs, webhook failure logs, and at least one raw-response warning path.
• Documentation explains how to enable deeper hardware diagnostics safely.

Verification gates

git diff --check
PYTHONPATH=. uv run --no-project --with pytest --with pytest-asyncio --with pytest-aiohttp --with pyserial-asyncio --with aiosqlite pytest tests/ -q

[Justinabox]

Additional privacy evidence from the current scout run: DTMF collection paths also log collected digits verbatim at DEBUG level. That is adjacent to this issue's "no secrets in logs" acceptance criteria because PBX/IVR deployments may collect account numbers, one-time codes, PINs, or menu secrets via DTMF.

No-hardware repro on current main (a7b1540):

PYTHONPATH=. uv run --no-project --with pytest --with pytest-asyncio --with pytest-aiohttp --with pyserial-asyncio --with aiosqlite python /tmp/callstack_dtmf_log_probe.py

Observed output using fake digits only:

collected: 123456
log_output:
callstack.voice.dtmf DEBUG DTMF received: 1
callstack.voice.dtmf DEBUG DTMF received: 2
callstack.voice.dtmf DEBUG DTMF received: 3
callstack.voice.dtmf DEBUG DTMF received: 4
callstack.voice.dtmf DEBUG DTMF received: 5
callstack.voice.dtmf DEBUG DTMF received: 6
callstack.voice.dtmf DEBUG DTMF collected: '123456'

Affected files:

• callstack/voice/dtmf.py:75-89 logs every received digit and the final collected string.
• callstack/voice/dtmf.py:131-145 repeats the same behavior for collect_from_stream().
• callstack/voice/ivr.py:113-127 logs IVR menu selections/invalid choices; single menu digits are usually less sensitive, but the DTMF collector itself can collect multi-digit secrets.

Suggested acceptance-criteria add-on:

• Default logs, including DEBUG logs intended for troubleshooting, should not contain raw multi-digit DTMF sequences. Prefer counts/lengths, redacted values, or an explicitly unsafe diagnostic opt-in.
• Add caplog tests proving raw collected DTMF sequences are absent while still leaving enough troubleshooting signal (digit count, timeout, terminator, etc.).

Duplicate checks before this comment:

gh issue list --repo Justinabox/Callstack --state all --search "DTMF logs digits IVR privacy PIN in:title,body"
# no matches

gh pr list --repo Justinabox/Callstack --state all --search "DTMF logs digits privacy"
# no matches

[Justinabox]

Additional current-main evidence from the issue-scout lane: URCDispatcher._log_safe_urc() still lets caller-ID URCs pass through debug logging unredacted, so a troubleshooting run at DEBUG can print the full +CLIP line before CallService's redacted caller-ID log sees it.

$ PYTHONPATH=. uv run --no-project --with pyserial-asyncio python -c '
import asyncio, logging
from callstack.events.bus import EventBus
from callstack.protocol.urc import URCDispatcher
async def main():
    logging.basicConfig(level=logging.DEBUG, format="%(name)s %(levelname)s %(message)s")
    await URCDispatcher(EventBus()).dispatch("+CLIP: \"+155****1234\",145")
asyncio.run(main())
' 2>&1
callstack.urc DEBUG URC: +CLIP: "+155****1234",145

The number above is a masked dummy, but production +CLIP payloads carry real caller IDs. This fits the existing acceptance criteria for raw URC/phone-number redaction; a focused regression can assert caplog.text excludes the raw +CLIP line while preserving a useful +CLIP:<redacted>/masked summary.

Baseline for this run remains green:

git diff --check  # exit 0
PYTHONPATH=. uv run --no-project --with pytest --with pytest-asyncio --with pytest-aiohttp --with pyserial-asyncio --with aiosqlite pytest tests/ -q
823 passed in 6.83s

[Justinabox]

Additional current-main privacy evidence: the packaged server's default auto-answer handler logs a full inbound caller ID at INFO level.

Reproduction (no hardware; fake modem/session only) on 6f35401:

PYTHONPATH=. uv run --no-project --with pytest --with pytest-asyncio --with pytest-aiohttp --with pyserial-asyncio --with aiosqlite python /tmp/callstack_server_caller_log_probe.py

Observed output contains the complete dummy test caller value in the server INFO log at server.py:487. The probe uses only a synthetic value; it does not contact a modem or use any real caller/SIM data.

Root cause: run_server()'s nested handle_call() formats session.number directly:

logger.info("Incoming call from %s — playing greeting", session.number)

This bypasses the existing redact_phone_number() helper already used by CallService for dialing, answering, and +CLIP handling. On an unattended PBX, INFO is a normal production level, so caller IDs can be copied into journal/centralized logs.

Affected file: server.py:486-489.

Suggested focused fix: log redact_phone_number(session.number) (and avoid broader call-flow changes).

Acceptance criteria:

• The auto-answer greeting path does not place a raw caller ID in INFO logs.
• A regression test invokes the registered run_server() call handler with a synthetic caller ID and asserts that caplog contains a masked value but not the raw value.
• Preserve the existing log's useful operational signal (incoming call / greeting).

Verification gates:

git diff --check
PYTHONPATH=. uv run --no-project --with pytest --with pytest-asyncio --with pytest-aiohttp --with pyserial-asyncio --with aiosqlite pytest tests/ -q

This is complementary to open PR #238, which covers DTMF collector logging only; it does not change server.py.