Proximo

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The public GitHub repository includes interim commits between releases — documentation, CI, and feature commits land on main between tagged releases (it is not only final releases), so work is reviewable as it progresses. Full commit history: https://github.com/john-broadway/proximo/commits/main

Repository on GitHub, which uses git. git is distributed.

Each release has a unique SemVer identifier (e.g., v0.20.0, v0.19.1, v0.19.0). The version is single-sourced — pyproject.toml, the package init, the git tag, and the CHANGELOG heading must agree — and a CI version-consistency job fails the build if they diverge, so every release carries exactly one unique, consistent version. https://github.com/john-broadway/proximo/releases

Every release is identified in version control with a git tag of the form vX.Y.Z (e.g., v0.20.0); the release process verifies the tag matches the version and the CHANGELOG top heading before it publishes. https://github.com/john-broadway/proximo/tags

Non-trivial release notes file in repository: https://github.com/john-broadway/proximo/blob/main/CHANGELOG.md.

This criterion applies only to Proximo's own results, not its dependencies. No publicly known, CVE-assigned run-time vulnerability has ever been reported against Proximo itself, so there are none to enumerate in any release's notes. Per this criterion's own guidance — "If there are no release notes or there have been no publicly known vulnerabilities, choose N/A" — N/A is the correct selection. (Proximo does maintain full human-readable release notes in CHANGELOG.md, and any future security fix would be recorded there.)

Non-trivial SECURITY[.md] file found file in repository: https://github.com/john-broadway/proximo/blob/main/SECURITY.md. [osps_do_02_01]

The project uses GitHub Issues as its issue tracker for individual issues. https://github.com/john-broadway/proximo/issues

Bug reports are submitted through GitHub Issues, which is monitored. The project has been public since 2026-06-11; no external bug reports have been filed to date, so none stand unacknowledged, and any received are acknowledged (a response, not necessarily a fix). https://github.com/john-broadway/proximo/issues

Enhancement requests are handled through GitHub Issues; none have been filed to date (public since 2026-06-11), and the tracker is monitored so requests are responded to. https://github.com/john-broadway/proximo/issues

GitHub Issues is a public, permanently URL-addressable, full-text-searchable archive of all reports and responses, open and closed. https://github.com/john-broadway/proximo/issues?q=is%3Aissue

The process is published on the project site in SECURITY.md: use GitHub private vulnerability reporting, with a direct "Report a vulnerability" link. https://github.com/john-broadway/proximo/blob/main/SECURITY.md

Private reporting is supported and documented: GitHub private vulnerability reporting opens a confidential advisory thread visible only to the reporter and the maintainer; SECURITY.md links it directly (…/security/advisories/new). https://github.com/john-broadway/proximo/blob/main/SECURITY.md

No vulnerability reports have been received to date (public since 2026-06-11), so none exceed the 14-day initial-response bar; SECURITY.md commits to acknowledging reports as quickly as practical.

Proximo is a Python package with a declared build backend (hatchling) in pyproject.toml; python -m build (or pip install . / uv build) rebuilds the wheel + sdist from source automatically, and the release workflow does exactly this in CI. https://github.com/john-broadway/proximo/blob/main/pyproject.toml

Built with standard, widely-used Python packaging tooling: hatchling (PEP 517 backend), the build frontend, uv, and pip. https://github.com/john-broadway/proximo/blob/main/pyproject.toml

Every build tool is FLOSS: Python, hatchling, build, uv, and pip. No proprietary tool is required at any step.

The project uses pytest (FLOSS) as its automated test suite (5,000+ tests, unit + structural doubles, mirrored test_<module>.py). How to run it is documented in CONTRIBUTING.md (uv run python -m pytest -q) and run automatically in CI. Docs: https://github.com/john-broadway/proximo/blob/main/CONTRIBUTING.md · CI: https://github.com/john-broadway/proximo/blob/main/.github/workflows/ci.yml

Invoked the standard Python way: pytest / python -m pytest. https://github.com/john-broadway/proximo/blob/main/CONTRIBUTING.md

A comprehensive suite (5,000+ tests) mirrors the source modules and exercises the mutation funnel, the trust-spine invariants, and each per-plane wrapper; the tamper-evident audit core is additionally checked against mutation. https://github.com/john-broadway/proximo/tree/main/test

GitHub Actions runs the full test suite plus lint on every push and pull request, across a Python 3.12/3.13 matrix, and a version-consistency + pip-audit + gitleaks gate alongside. https://github.com/john-broadway/proximo/blob/main/.github/workflows/ci.yml

CONTRIBUTING.md states the policy explicitly: "new behavior needs a test; a bug fix needs a test that fails before the fix and passes after," and a PR that doesn't pass the full suite won't merge. https://github.com/john-broadway/proximo/blob/main/CONTRIBUTING.md

The policy is adhered to: recent feature work (e.g., PDM fleet control, the backup-freshness fence) shipped with its tests, the tests/tree mirrors the source module-for-module, and CI blocks any merge whose suite isn't green — so untested changes cannot land. https://github.com/john-broadway/proximo/tree/main/tests

The add-tests policy is documented in the change-proposal instructions, in CONTRIBUTING.md's "Submitting a change" section (step 2: "Make the change with tests"). https://github.com/john-broadway/proximo/blob/main/CONTRIBUTING.md

The project runs ruff (a FLOSS linter) as a required, blocking CI check, plus pyright static type-checking on the src scope as a development gate. https://github.com/john-broadway/proximo/blob/main/.github/workflows/ci.yml

Warnings are addressed, not ignored: ruff check . is a blocking CI step, so any lint finding reds the build and a PR cannot merge until it's clean. https://github.com/john-broadway/proximo/blob/main/.github/workflows/ci.yml

The posture is strict-by-default: the lint gate treats any finding as a failure (no warn-and-continue), and static typing is enforced over the shipped src scope. https://github.com/john-broadway/proximo/blob/main/pyproject.tom

The primary developer designed Proximo around an explicit security model: least-privilege scoped Proxmox tokens (the hard floor enforced server-side), fail-closed defaults, defense-in-depth, and a documented two-deployment trust model that honestly distinguishes a real boundary from an in-process speed bump. Demonstrated in SECURITY.md and THREAT_MODEL.md. https://github.com/john-broadway/proximo/blob/main/SECURITY.md

The project identifies and mitigates the vulnerability classes specific to an AI-driven control plane: prompt injection (the opt-in TAINT control on adversarial reads), command/exec injection (opt-in, fail-closed CTID/agent allowlists), secret leakage (secrets-by-reference, gitleaks, a modeled-tree leak audit), and supply-chain (SHA-pinned actions, SBOM, signed provenance, blocking pip-audit/Trivy/CodeQL). Each is documented with its mitigation. https://github.com/john-broadway/proximo/blob/main/THREAT_MODEL.md

Only standard, published, expert-reviewed primitives: TLS (Proxmox API transport), SSH (exec edge), HMAC-SHA256 (audit ledger), SHA-256 (content/cert digests), and ECDSA via the cryptography library (A2A agent-card signing). No bespoke crypto.

Proximo's purpose is not to implement cryptography, and it doesn't roll its own: it calls Python's stdlib hmac/hashlib and the cryptography library (src/proximo/audit.py, src/proximo/a2a/signing.py), plus the platform's TLS/OpenSSH. https://github.com/john-broadway/proximo/blob/main/src/proximo/a2a/signing.py

Every crypto-dependent path is implementable with FLOSS: OpenSSL (TLS), OpenSSH, Python's stdlib hmac/hashlib, and the cryptography library — all FLOSS.

The only key Proximo itself generates is the audit-ledger HMAC key, minted at 256-bit (secrets.token_bytes(32)); digests are SHA-256; A2A signing uses NIST EC via cryptography; transport keylengths come from the system TLS/SSH stacks. All meet or exceed the NIST-through-2030 minimums, and Proximo exposes no weak-keylength option to enable.

A source scan confirms no MD5, SHA-1, single-DES, RC4, or Dual_EC_DRBG anywhere; default security mechanisms are SHA-256 / HMAC-SHA256 / EC. No broken algorithm is used or required.

No dependence on known-weak algorithms or modes: no SHA-1 in any security mechanism, and the SSH edge uses OpenSSH's modern default KEX/ciphers (no forced CBC).

Proximo implements no key-agreement protocol of its own; the transports it depends on provide perfect forward secrecy — TLS via ECDHE and SSH via (EC)DH.

Proximo stores no passwords for authenticating external users. It authenticates to Proxmox with an operator-provided API token passed by reference (a file path, never inlined or stored), and the optional A2A face uses an operator-supplied bearer token. There is no user-password store.

Cryptographic key material is generated with a CSPRNG: the audit-ledger key uses secrets.token_bytes(32) (src/proximo/audit.py). No insecure generator (random) is used for any security purpose. https://github.com/john-broadway/proximo/blob/main/src/proximo/audit.py

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Distribution is HTTPS-only (PyPI, GHCR); pip/uv verify package hashes over TLS, and the container image is pulled over HTTPS. No cryptographic hash is ever fetched over plain HTTP and used unverified; releases additionally carry sigstore-signed build provenance.

There are no known unpatched vulnerabilities of medium or higher severity in Proximo. CodeQL, Trivy, and pip-audit run continuously; pip-audit and Trivy are blocking CI gates, so a known-CVE dependency reds the build until patched. https://github.com/john-broadway/proximo/blob/main/.github/workflows/ci.yml

No critical vulnerability has been reported against Proximo; the blocking CVE gates force dependency fixes to land before merge, and SECURITY.md commits to rapid, coordinated fixes for anything reported.

No valid private credential is committed, and it's enforced at multiple layers: gitleaks scans full history in CI, a release leak-audit models the exact public tree and refuses to publish if any secret/credential shape appears (then runs gitleaks over that modeled tree), and the project's secrets-by-reference discipline means tokens are passed by file path and never enter the repo. https://github.com/john-broadway/proximo/blob/main/.github/workflows/ci.yml

Two FLOSS static analyzers run before every release (releases are cut from main, which both gate): CodeQL (semantic SAST over the shipped src/) and ruff including the S/flake8-bandit security ruleset, plus pyright static typing. https://github.com/john-broadway/proximo/blob/main/.github/workflows/codeql.yml

Both tools carry vulnerability-finding rules: CodeQL's Python security queries (injection, path traversal, unsafe deserialization, clear-text logging, etc.) and ruff's S (flake8-bandit) rules for common insecure patterns — deliberately enabled because Proximo drives a hypervisor. https://github.com/john-broadway/proximo/blob/main/pyproject.toml

CodeQL findings surface in the GitHub Security tab and the shipped-src baseline is clean; the analysis scope is documented (dev-only scripts excluded to avoid 32 false positives, not to hide findings), and confirmed issues are fixed before release. https://github.com/john-broadway/proximo/blob/main/.github/codeql/codeql-config.yml

CodeQL runs on every push to main, on every pull request, and on a weekly schedule; ruff's security lint runs on every push and PR in CI. https://github.com/john-broadway/proximo/blob/main/.github/workflows/codeql.yml

Every proposed release is exercised by a large automated suite (5,000+ pytest tests) that dynamically runs the code with runtime assertions across a Python 3.12/3.13 matrix, with the trust-spine core additionally checked against mutation; a separate live-smoke harness dynamically exercises the tool surface against a real Proxmox host. (Honest note: there is no fuzzer/sanitizer — those target memory-unsafe languages; see next item.) https://github.com/john-broadway/proximo/blob/main/.github/workflows/ci.yml

Proximo is pure Python (a memory-safe language) and produces no C/C++ or other memory-unsafe code, so a memory-safety dynamic tool is not applicable.