Skip to content

Security: MrScripty/Pumas-Library

Security

docs/SECURITY.md

Security

Reporting a Vulnerability

Do not open a public issue for a suspected vulnerability. Use the repository's private vulnerability reporting channel or contact the maintainer privately. Include affected versions, reproduction steps, impact, and any known mitigation.

Only the latest development/release line receives security fixes unless a maintainer explicitly announces otherwise.

Current Trust Boundaries

  • The Electron renderer is sandboxed and isolated from Node. Privileged actions cross the preload/main IPC boundary.
  • Electron validates RPC method names and some request shapes before forwarding to the Rust sidecar. Coverage is incomplete; renderer TypeScript types are not a security boundary.
  • pumas-rpc binds to loopback by default and limits body size and concurrent requests.
  • pumas-rpc --allow-lan currently has no caller authentication or authorization. Do not expose it to an untrusted network.
  • The Torch sidecar is loopback-only by default. Non-loopback use requires both PUMAS_TORCH_ALLOW_LAN=1 and PUMAS_TORCH_API_TOKEN; all routes except /health then require the token.
  • Model paths, import roots, URLs, archives, and generated runtime commands are privileged inputs and must be validated at their receiving boundary.

Sensitive Data

Hugging Face tokens and other secrets must never appear in logs, errors, URLs, or diagnostics. pumas-rpc does not log request parameter values, including in debug mode. Request diagnostics use an allowlisted method label, a numeric request ID when present, and a stable outcome class/code.

JSON-RPC and RPC-owned event errors pass through the Rust producer's stable public error projection. Its messages are bounded and deny disclosure of raw internal path, URL, credential, dependency, and upstream error text. Internal errors must not be serialized through Display or Debug; new transports must reuse the same projection.

Dependency and Release Evidence

Authoritative dependency inputs are the checked-in Cargo and pnpm lockfiles plus the Python requirements under torch-server/. The Torch production requirements are not currently resolved into a reproducible lock.

Before a release, run current vulnerability and license checks against the resolved shipped dependency closure for all three ecosystems. Record tool versions and results with the release evidence. Do not rely on removed SBOM or scan snapshots; they described obsolete dependencies and were not generated by the current release workflow.

Useful local tools include cargo audit, npm audit, and pip-audit, but a tool result is meaningful only when its inputs match the final artifact.

Current Security Work

Security and boundary findings are prioritized in the current standards audit. Credential-safe diagnostics and the RPC/LAN threat model are the first required remediation slice.

There aren't any published security advisories