Skip to content

Review follow-ups: media cache-on-error, viz path confinement, whatsmeow read handle #39

Description

@MaxGhenis

Low-priority items from the 2026-06-12 deep review, verified but deliberately not rushed into the hardening batch (#31):

  1. Media handlers discard w.Write errors and pre-set 24h cacheinternal/web/api.go /api/media/ and /api/whatsapp/avatar handlers set Cache-Control: public, max-age=86400 before writing and ignore the write error, so a truncated body can be cached for a day by the browser. Check the platform fetch fully succeeded before setting cache headers; log dropped writes.

  2. render_story / generate_viz accept arbitrary output_path / photo_pathsinternal/tools/render_story.go writes caller-named paths and reads caller-named files. This is by design for story exports, and MCP runs with operator trust behind the loopback guard + injection preamble — but a prompt-injected agent could be steered into writing HTML to e.g. ~/Library/LaunchAgents/. Consider confining writes to ~/Documents/OpenMessage/ (or an OPENMESSAGES_EXPORT_DIR) with an explicit env escape hatch, mirroring how download_media confines to the temp dir.

  3. Second read-only SQLite handle on whatsmeow's live session DBinternal/whatsapplive/client.go (lookupPN/LIDFromSessionStore) opens whatsapp-session.db read-only per call on the message hot path while whatsmeow holds it for writes. WAL+ro is normally fine; worth a comment documenting the cross-handle dependency and a cached handle instead of open/close per lookup.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions