Printing Press Install — v4.0.3 (2026-05-07)

Decision summary

Founder greenlit install on 2026-05-07 after a security review returned PASS-with-mitigations. Maintainer identity (Matt Van Horn, June co-founder, ex-Lyft origins) and distribution model (no curl|sh, no postinstall scripts, signed Go releases with checksums.txt) cleared the SOP bar. Real risks live in downstream usage, not in the binary itself.

Cross-link: ~/rdco-vault/02-sops/2026-05-02-mcp-plugin-skill-install-security-review-sop.md — the review framework applied here.

Install record

Mitigations applied at install

1. Pinned to a specific version, not @latest. Used pre-built v4.0.3 tarball. Disables silent upgrade.
2. Did NOT run starter-pack install. No community CLIs were pulled. Library starts empty.
3. Did NOT use go install path. Go toolchain is not installed on this machine. Pre-built release binary path was chosen for verifiable integrity (SHA-256 against published checksums.txt).
4. Did NOT use npx -y @mvanhorn/printing-press — that npm package shims out to a Go binary and would have implicitly required Go anyway, plus would have used @latest semantics from npm.
5. Verified SHA-256 BEFORE extract. Downloaded tarball + checksums.txt to a tmp dir, ran shasum -a 256 -c, only extracted after OK.
6. Inspected binary signature (codesign -dvv). Adhoc-signed Go binary, no Developer ID — matches expectations for unstapled Go releases. No Apple notarization, but provenance is established via the SHA chain.
7. Cleaned up tmp dir after install. No tarball or scratch files left on disk.

Mitigations to enforce on every future use

These are the operational guardrails. Each of these is a hard rule until proven otherwise:

• No community CLIs without per-CLI security review. The 46 CLIs in mvanhorn/printing-press-library are gated only by mechanical PR checks (go build, go vet, --help responds, manifest present). A malicious PR slipping past those gates would ship arbitrary Go code. Each npx ... install <name> or printing-press library install <name> requires its own SOP review run.
• API keys via env var only. Never let a generated CLI persist a token to ~/printing-press/. If a generated CLI tries to write a credential to disk, route through 1Password CLI wrapper instead (per feedback_no_secrets_on_disk memory).
• Public-data APIs only. Press’s local SQLite mirror lives plaintext at ~/printing-press/library/<api> and ~/printing-press/.runstate/. Do NOT mirror APIs RDCO already has via 1Password-gated MCPs (Stripe, Gmail, Notion, Monarch, etc.). Press is for public-data APIs (sports stats, weather, public registries, civic data, etc.) where local mirroring is the win.
• Skip the browser-sniff gate unless the target API has no public spec. The browser-sniff feature launches Chromium to capture API traffic — it’s the largest attack surface. printing-press generate from a public OpenAPI/discovery doc avoids this entirely.
• Audit ~/printing-press/ periodically. Watched-path candidate for the future security-monitor skill. Today, manually ls -la ~/printing-press/ after every press run to confirm nothing escaped that subtree.
• Pin upgrades. Future version bumps go through a fresh security review per the install-vs-update policy memory (feedback_skill_install_first_vs_update_policy). Don’t auto-pull v4.0.4 because it published.

What Press is good for (RDCO-fit cases)

• Forward-looking: when an API-only integration shows up that does NOT have an MCP server yet, generating an agent-optimized CLI from the API’s OpenAPI/discovery spec is faster than writing one by hand.
• Local-SQLite-mirror primitive: if/when RDCO needs high-volume public-data scraping (e.g. content radar across SEC filings, civic data drops, sports/finance public APIs) where token cost > setup cost, the mirror beats raw HTTP fan-out.
• MCP server emission: every press run produces a <api>-pp-mcp MCP server alongside the CLI. Lets RDCO grow the MCP surface area without writing servers by hand.

What Press is NOT for (don’t reach for it here)

• Anything we already have an MCP for. Notion, Gmail, Calendar, Monarch, Stripe, Slack, Cloudflare, ElevenLabs, HeyGen, Canva, Figma, Discord, iMessage, X — all covered, all credentialed, all 1Password-gated. Don’t duplicate.
• Reddit (queued PullPush MCP exists separately — that path is mature, doesn’t need Press).
• Any flow that requires storing customer or financial credentials.

Sub-agent security review (full text reference)

Verdict: PASS-WITH-MITIGATIONS. Source trust strong (Matt Van Horn / mvanhorn, June co-founder, deep OSS history). Repo health good (256 stars, MIT, 44 releases, active cadence). Distribution clean (no curl|sh, no preinstall/postinstall, npm package is a thin shim, Go releases use sumdb). Real risks: SQLite mirror is plaintext at rest, generated-CLI credential storage path is undocumented, community CLI catalog has only mechanical PR gates. All three are managed by the install + use mitigations above.

Open questions worth watching:

• Where exactly do generated CLIs persist credentials? Read one generated CLI’s source before first real use.
• Is there a CODEOWNERS / required-review setting on the library repo?
• Does Press make any outbound calls during generation beyond the target API + browser-sniff?

Related

• ~/rdco-vault/02-sops/2026-05-02-mcp-plugin-skill-install-security-review-sop.md
• ~/rdco-vault/06-reference/2026-05-07-writewithai-voc-landing-page-claude-code.md — same-day intake that surfaced the agent-CLI pattern via PullPush
• ~/rdco-vault/06-reference/2026-05-07-every-anthropic-2026-developer-conference.md — Anthropic Managed Agents (where the multiagent + MCP-server primitives are codified)
• Feedback memory: feedback_no_secrets_on_disk — 1Password wrapper as the credential store of record
• Feedback memory: feedback_skill_install_first_vs_update_policy — install-now vs upgrade-later differential security posture
• Feedback memory: feedback_mcp_install_security_review_default — security review SOP applies to MCP/plugin/skill installs by default

Changelog

• 2026-05-07 20:07 ET — Install completed. Pre-built v4.0.3 darwin_arm64 binary, SHA-256 verified, mitigations applied.