Report suspected vulnerabilities privately through GitHub private vulnerability reporting. Do not open a public issue for a vulnerability. Do not include secrets, managed values, backup passwords, or unredacted installation receipts in a report.

Include a concise description, affected Envman version or release asset, reproduction steps, impact, and sanitized logs. A maintainer may ask for additional evidence or coordinate disclosure after the issue is understood.

This policy covers Envman's source, release installer, published release assets, and repository automation. It does not make the local uv executable, Python runtime, shell configuration, GitHub account, PyPI, or the rest of the machine part of Envman's security boundary.

Envman masks sensitive values in ordinary TUI and CLI output, but a caller that requests --reveal or receives the process environment can still obtain them. New managed configurations and automatic environment snapshots use authenticated encryption. The prompt-free storage key is kept in a private file under the user's state directory, so copying both that key and the ciphertext defeats this protection. An unlocked user or root can also retrieve values. Existing plaintext configurations encrypt on their next save; envman migrate-storage --apply also converts historical environment snapshots. External and filesystem backups remain outside Envman's control. Encrypted export files use a separate ENVMAN_BACKUP_KEY or approved backup key file; protect that credential separately.

The verified installer checks release-manifest structure, GitHub asset URLs, sizes, SHA-256 hashes, wheel metadata, runtime constraints, and compatibility before installation. It still trusts the local uv executable and Python runtime, GitHub release hosting, and the dependency index used for exact runtime wheels. See installation sources and updates.