[notpeter]

Harden the handling of PDF generation with Ascii doctor on the server.

• RFDs with malicious payloads could read arbitrary files from the server at PDF generation time so run asciidcotor-pdf in "safe mode" and filter environment variables.
• download_supporting_documents could escape from within the rfd-specific working directory (e.g. via .. in paths) so sanitize those paths first.

🤖 Robot Voice:

The asciidoctor-pdf command line defaults to the unsafe safe mode, so RFD content could include:: arbitrary files (absolute or parent-relative paths) or point pdf-theme at a YAML file elsewhere on disk and have its contents embedded in the published PDF. The renderer also inherited the processor's full environment, including any configuration supplied through it.

Run asciidoctor-pdf with -S safe and the render directory as the base dir so includes and relative images are jailed to it, lock the pdf-theme, pdf-themesdir and pdf-fontsdir attributes (asciidoctor-pdf does not jail them) so documents cannot override them, and pass the child only the environment variables needed to locate Ruby, Node and Chromium.

download_supporting_documents built local paths by deleting every rfd/NNNN from the repository path, so an RFD committer could pick directory names that collapse into .. and write files outside the render directory. The new supporting_document_path helper strips only the leading RFD directory. It skips any path that is empty or contains anything other than ordinary file and directory names, so every write stays under /rfd-render//. Unit tests cover the crafted path and the rejected cases.

Claude links (internal-only):

• Finding 1: https://claude.ai/security/findings/find_01Q27zXnAec1pYnK858Z6BF2
• Finding 2: https://claude.ai/security/findings/find_011CgtDtPXvwSESMuGbtmj9H
• Claude-Session: https://claude.ai/code/session_01Q5Ej2cHBc7wgaksc9BPkai