polymath-os

Publicly available repository: https://github.com/rtynbirf/polymath-os

Git is used for version control with public commit history (README Quick start: git clone https://github.com/rtynbirf/polymath-os.git).

The public git repository contains the full interim commit history between releases (trunk-based development; e.g. 39 commits between v3.21.1 and v3.25.0 per CHANGELOG.md).

Distributed version control (git) is used; the README explicitly invites forking the whole repo.

Each release has a unique version identifier (MAJOR.MINOR.PATCH, e.g. v3.25.0) recorded in CHANGELOG.md; git commit IDs uniquely identify interim states.

Version identifiers follow semantic versioning (v1.0.0 through v3.25.0 in CHANGELOG.md; current version v3.25.0 is stated in README.md).

Each release is identified with a git tag: .github/workflows/release.yml triggers on push of tags 'v*..' and creates a GitHub Release from it.

CHANGELOG.md provides human-readable, per-release summaries of major changes (Keep a Changelog style, v1.0.0 → v3.25.0); .github/workflows/release.yml extracts each version's section into the GitHub Release body. https://github.com/rtynbirf/polymath-os/blob/main/CHANGELOG.md

There are no publicly known run-time vulnerabilities with a CVE assignment (or similar) that were fixed in a release of this project; CHANGELOG.md 'Security' sections document hardening work only.

A process for submitting bug reports is provided: GitHub Issues (templates in .github/ISSUE_TEMPLATE/bug_report.yml); security vulnerabilities are reported privately per SECURITY.md. https://github.com/rtynbirf/polymath-os/issues

GitHub Issues is used as the public issue tracker: https://github.com/rtynbirf/polymath-os/issues (templates: .github/ISSUE_TEMPLATE/bug_report.yml, feature_request.yml).

All bug reports and dependabot PRs in the last two months have been acknowledged and resolved (recorded in CHANGELOG.md and merged PRs: dependabot #11, #13 biome fix, PR#12 membrane, etc.); there are no unacknowledged bug reports. Tracker: https://github.com/rtynbirf/polymath-os/issues

No enhancement requests are open from the last two months (GitHub Issues used for bug reports; feature discussion happens in issues/PRs and is answered: e.g. dependabot and membrane PRs #11/#12/#13 were reviewed and merged). Majority-response criterion holds for the small request volume; https://github.com/rtynbirf/polymath-os/issues

Reports and responses are publicly archived and searchable in GitHub Issues: https://github.com/rtynbirf/polymath-os/issues

SECURITY.md publishes the vulnerability reporting process: private GitHub Security Advisories as the single channel (https://github.com/rtynbirf/polymath-os/security/advisories/new); coordinated disclosure (public advisory with CVE after fix + release); response times of <=72h for acknowledgment and <=7 days for initial assessment. https://github.com/rtynbirf/polymath-os/blob/main/SECURITY.md

Private vulnerability reporting is supported: SECURITY.md directs reporters to GitHub private security advisories (https://github.com/rtynbirf/polymath-os/security/advisories/new) as the single channel and explicitly forbids opening public issues for vulnerabilities.

No vulnerability reports have been received in the last 6 months (single-maintainer research project). The documented policy in SECURITY.md commits to acknowledging reports within 72 hours and an initial assessment within 7 days, both within the 14-day requirement.

The runtime requires no build: it is zero-dependency Python 3.10+ standard library that runs directly from source (python runtime/src/demo.py; 'no installation required' per README). Where building applies (JS apps), a working build system is provided: pnpm + Turborepo (turbo run build) validated in CI (.github/workflows/ci.yml) and a Makefile entry point (make build).

Common FLOSS build tools are used: Make (Makefile), pnpm 9 + Turborepo, Python, Nix (flake.nix); make verify runs scripts/check.py.

The build and CI toolchain is entirely FLOSS: make, Python, pnpm, Turborepo, Nix, GitHub Actions, gcc-free stdlib-only Python code.

Automated test suites are publicly released as FLOSS in the repository: 295 runtime tests under runtime/tests/ (unittest-discoverable, also pytest-compatible) including RFC 8032 Ed25519 test vectors, durability, integration and mutation-fuzz tests, plus MCP adapter tests (tooling/agents/mcp/tests/). Invocation is documented in README.md (make test, make verify) and runtime/README.md (python scripts/check.py).

Standard invocation for the language: make test at the repo root; cd runtime && python3 scripts/check.py (runs python -m unittest discover -s tests); PYTHONPATH=. python3 -m tooling.agents.mcp verify --coverage for MCP tests; pytest is also configured via runtime/pyproject.toml ([tool.pytest.ini_options]).

.github/workflows/ci.yml runs on every push/PR to main: make verify, lint, typecheck, runtime + MCP tests, build, and security scans (README badge: 'CI 5/5 green').

CONTRIBUTING.md states required local checks for every change (make bootstrap && make lint && make typecheck && make test && make ci-local) and the repo keeps a per-module test policy: runtime/tests/ holds 295 tests (unittest-discoverable, pytest-compatible) with dedicated test files per module; ADR-driven changes ship with tests (e.g., ADR-0023/0024 came with +33 tests recorded in CHANGELOG v3.10.0). https://github.com/rtynbirf/polymath-os/blob/main/CONTRIBUTING.md

Evidence in git history and CHANGELOG.md: new functionality ships with tests — v3.10.0 added 33 tests for AgentCard/AgentMesh, v3.x added durability/fuzz/mutation tests (runtime/tests/test_fuzz_parsers.py, test_durability.py), MCP adapters have their own suite (tooling/agents/mcp/tests/). make verify (33/33) and make test pass on every CI run.

The test-addition policy is documented in CONTRIBUTING.md (required local checks incl. make test; per-module test layout in runtime/tests/; pytest configured in runtime/pyproject.toml) and the README documents test invocation (make test / make verify).

Linter and warning-detection tools are enforced in CI: Biome (pnpm turbo run lint), TypeScript compiler checks (pnpm turbo run typecheck), and python -m py_compile over runtime sources (runtime/scripts/check.py 'compile' step).

Warnings must be fixed to pass CI: lint (Biome) and typecheck are required status checks in .github/workflows/ci.yml; the compile check must exit 0 for make verify to pass. CHANGELOG records lint fixes (e.g. biome lint fix in apps/browser/decree-bridge.js, v3.20.0).

CI blocks on strict static checks: Biome lint (error-level, pnpm turbo run lint) and TypeScript strict-mode typecheck are required status checks; python -m py_compile plus the repo's own scripts/check.py must exit 0. Warnings are fixed, not waived (CHANGELOG records lint fixes).

Secure-design knowledge is documented in-repo: runtime/docs/THREAT_MODEL.md (attacker model, trust boundaries), SECURITY.md (disclosure process), ADR-0029 (Singulyar security model), ADR-0031 (Ed25519 decree signing, RFC 8032 test vectors), docs/COMMIT_SIGNING.md, SLSA build targets (ADR-0004/0013). The runtime implements tamper-evident hash-chained append-only decree log.

Common error classes are covered by dedicated tests and docs: failure injection and crash durability (runtime/tests/test_durability.py), tampered messages/keys/signatures rejected honestly (test_decree_signing.py with RFC 8032 vectors), input validation fuzzing (test_fuzz_parsers.py over parsers), circuit breaker and error-path tests; runtime/docs/LIMITATIONS.md records known limits honestly.

The only cryptography used (runtime/src/decree_signing.py, ADR-0031) is Ed25519 signatures as specified in RFC 8032 and SHA-256 hash chains — both publicly published and expert-reviewed; no proprietary or custom-designed algorithms.

All crypto functionality is implemented in-repo as MIT-licensed FLOSS (runtime/src/decree_signing.py); Ed25519 (RFC 8032) and SHA-256 are unencumbered open standards.

Only Ed25519 (256-bit elliptic curve, above the NIST 224-bit minimum) and SHA-256 (256-bit, above the 224-bit hash minimum) are used; the software supports no smaller keylengths that would need to be disabled.

No broken algorithms are used (no MD5, single DES, RC4, SHA-1, Dual_EC_DRBG; no ECB). Security mechanisms use SHA-256 hash chains and Ed25519 signatures; runtime/tests/test_decree_signing.py validates against official RFC 8032 test vectors and verifies that tampered messages, wrong keys and invalid signatures are rejected (verified=False, honest failure reasons).

Ed25519 and SHA-256 do not have known serious weaknesses; no SHA-1, no CBC mode in SSH, no other weak algorithms or modes are used.

There are no key-agreement or session protocols: cryptography is limited to offline signing of hash-chained decree records in a local SQLite database. No network transport is part of the security mechanism, so perfect forward secrecy is not applicable.

The software does not store passwords for authenticating external users (no inbound password authentication exists in the runtime or the apps).

The software generates no cryptographic keys or nonces: Ed25519 signing is deterministic per RFC 8032, and signing keys are generated externally with ssh-keygen (CSPRNG). runtime/src/decree_signing.py contains no random number generator calls.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

All artifacts are delivered only via GitHub Releases over HTTPS; no cryptographic hashes are retrieved over http. The release pipeline (.github/workflows/release.yml) builds, runs make verify, generates CycloneDX SBOM, cosign-signs it keyless (OIDC) and attaches SLSA in-toto provenance (sbom.slsa-provenance.intoto.jsonl) to every release asset.

No known unpatched vulnerabilities of medium or higher severity: CodeQL (js/ts+python, security-and-quality), Semgrep and Trivy run in CI; gitleaks enforces token hygiene (a 2026-10-17 leak was auto-detected and revoked within minutes, documented in SECURITY.md). Private disclosure via GitHub Security Advisories per SECURITY.md; no open findings at the time of this entry.

No critical vulnerabilities have been reported or discovered (Code Scanning clean; CodeQL security-and-quality, Semgrep, Trivy in CI). The single security incident (leaked token, 2026-10-17) was auto-detected and revoked within minutes and documented in SECURITY.md.

CI runs gitleaks (.github/workflows/ci.yml) and make verify includes scripts/check_token_hygiene.py (claim #23) scanning all .py/.sh/.js/.yml/.md files for plaintext GitHub PAT patterns; SECURITY.md documents token hygiene rules and pre-commit gitleaks. One historical incident (2026-10-17) is documented in SECURITY.md: the leaked token was auto-detected and revoked by GitHub secret scanning within minutes, and lessons learned were recorded.

Static analysis is applied to proposed releases: CodeQL analyzes both javascript-typescript and python with the +security-and-quality query pack (.github/workflows/codeql.yml, results to GitHub Code Scanning as SARIF); Semgrep (semgrep scan --config auto) and Trivy filesystem scan run in CI (.github/workflows/ci.yml); Biome lints JS/TS.

CodeQL uses the security-and-quality query pack targeting common vulnerabilities; Semgrep uses --config auto, whose ruleset includes language vulnerability rules; both upload findings to GitHub Code Scanning.

Static analysis findings are fixed to pass CI: CodeQL security-and-quality scan uploads to GitHub Code Scanning with no open medium+ findings; Semgrep (--config auto) and Trivy fs scan are required CI steps; lint (Biome) and typecheck are blocking checks. CHANGELOG records lint/security fixes per release.

CodeQL runs on every push and PR to main plus a weekly schedule (cron '0 6 * * 1'); Semgrep and Trivy run on every CI run (.github/workflows/ci.yml, .github/workflows/codeql.yml).

Dynamic analysis (fuzzing) is part of the test suite: runtime/tests/test_fuzz_parsers.py performs deterministic mutation fuzzing (stdlib-only, fixed SEED 20261107) over parser surfaces (schema_validate.validate, AgentCard.from_dict, ConversationalDecreeInterface.translate) and runs within make verify / CI (295 runtime tests).

The produced software is written in memory-safe languages only (Python 3.10+ stdlib runtime; JavaScript/TypeScript apps) — there is no memory-unsafe code (C/C++/Rust in production paths) whose unsafe operations would need dynamic-analysis instrumentation.

Dynamic analysis (deterministic mutation fuzzing over parser surfaces — runtime/tests/test_fuzz_parsers.py, fixed SEED 20261107) runs under CPython in CI with assertions enabled by default (no python -O anywhere in CI/make targets); unittest/pytest failures are blocking.

No medium-or-higher vulnerabilities have been discovered by dynamic analysis so far; the fuzz suite runs green in every CI run (295/295 tests). Any future finding would be fixed per the documented policies (CONTRIBUTING.md, SECURITY.md).