boost

https://github.com/jonnyeclectic/boost/blob/main/SUPPORT.md documents the policy and the upgrade path. Only the latest release is supported, and the upgrade is a single command ('pipx upgrade boost-skill-cli'), which is practical here rather than aspirational: the runtime is standard-library only so there is no dependency resolution to break, versions come from git tags via setuptools-scm, and no configuration migration is required between patch releases. Because a release is cut on every merge, the gap between an installed version and the fixed one is small by construction.

GitHub Issues, used as the sole tracker: https://github.com/jonnyeclectic/boost/issues

MAINTAINERS.md states the policy in the roles table: 'Security reporter - anyone who reports a vulnerability through the process in SECURITY.md. Reporters are credited by name in the advisory and the release notes unless they ask not to be.' https://github.com/jonnyeclectic/boost/blob/main/MAINTAINERS.md . No vulnerability has been reported to date, so the policy has not yet had an occasion to be exercised.

https://github.com/jonnyeclectic/boost/blob/main/SECURITY.md states the channel, the expected acknowledgement time, and what a useful report contains. [vulnerability_report_process] [osps_vm_01_01]

https://github.com/jonnyeclectic/boost/blob/main/CONTRIBUTING.md#ground-rules states the coding standards: standard-library only at runtime, the cli -> commands -> core layering rule with core importing neither of the outer layers, new commands as def cmd_<name>(argv) -> int dispatched lazily from cli.py, behaviour changes requiring tests, and everything under boost_cli/core being mutation-tested. Style itself is delegated to tooling rather than prose - the ruff configuration in pyproject.toml states the enabled rule families explicitly, with comments explaining each choice.

Enforced mechanically on every pull request as required checks, not by review: ruff (an explicitly enumerated rule set - E/F, flake8-bandit S, bugbear B, SIM, C4, PERF, RUF, pyupgrade UP, isort I), mypy and pyright as two independent type checkers, vulture for dead code, xenon as a complexity ratchet, refurb for modernization smells, and import-linter enforcing the layering rule from CONTRIBUTING. Zero findings are permitted from any of them - a single finding fails the build - so a standard cannot erode gradually. pre-commit runs the same tools locally before a commit is made.

boost produces no native binaries. It is a pure-Python package built with the standard PEP 517 toolchain from pyproject.toml, so there is no compiler or linker invocation and CC, CFLAGS, CXX, CXXFLAGS and LDFLAGS have nothing to be honoured by.

There is no compilation step and therefore no debugging information to strip or preserve. Python source is installed as source; tracebacks carry full file and line information by construction.

There is no recursive build. The package is built in one PEP 517 invocation from a single pyproject.toml with no subdirectory build systems and no cross-dependencies between them.

A build is repeatable and its inputs are pinned by hash. requirements/*.txt pin an exact version and every artifact's sha256 for the full transitive closure of the toolchain, enforced by pip --require-hashes, so a contributor's make venv and a CI runner resolve to identical bytes; scripts/lock_toolchain.py --check runs in the lint gate and fails on drift between the .in declaration and the locked .txt. The runtime itself has no third-party dependency to vary. The version is derived deterministically from the git tag by setuptools-scm rather than from a hand-edited constant, and noxfile.py reproduces the exact CI gate in isolated environments across every supported interpreter.

Installation uses the standard Python mechanisms and nothing bespoke: pipx install boost-skill-cli (recommended, for an isolated CLI) or pip install boost-skill-cli. The package is published to PyPI with standard metadata, so any conventional Python installation method works. Prerequisites are Python 3.12+ and git, stated in the README.

There is no bespoke installation system whose destination boost chooses. Installation is performed by pip or pipx, which already honour the standard Python conventions (--prefix, --target, --user, virtual environments and PEP 668 handling); DESTDIR is a POSIX build-system convention that does not apply to a wheel installed by pip.

https://github.com/jonnyeclectic/boost/blob/main/CONTRIBUTING.md documents the build from a clean clone: 'make venv' installs every gate tool from the hash-pinned requirements, and the full gate table lists each command. noxfile.py reproduces the exact CI gate in isolated venvs across every supported interpreter, so 'green on my machine' and 'green in CI' mean the same thing. Prerequisites are Python 3.12+ and git, stated in the README; the runtime itself has no third-party dependencies. [osps_do_07_01]

Dependencies are ingested with standard ecosystem tooling only - pip, driven by pyproject.toml for the project's own extras and by requirements/*.txt for the toolchain. Those lock files pin an exact version and every artifact's sha256 for the full transitive closure, enforced by pip --require-hashes, so a build resolves to identical bytes on a contributor's machine and on a CI runner. Nothing is vendored or fetched ad hoc. See https://github.com/jonnyeclectic/boost/blob/main/docs/dependencies.md [osps_br_05_01]

https://github.com/jonnyeclectic/boost/blob/main/docs/dependencies.md documents the monitoring and the thresholds. Dependabot proposes upgrades; pip-audit fails the build when a resolved dependency matches a known OSV or PyPI advisory and also runs on a weekly schedule so a newly published advisory against unchanged code is still caught; OSV-Scanner runs diffed against the base branch and fails on what a pull request adds; a licence gate fails on a licence outside the allowed set; and a CycloneDX SBOM is generated per released wheel. pip-audit and osv-scan are both required checks. The runtime has no third-party dependency to monitor, which is the strongest form of this.

pyproject.toml declares the project's direct dependencies (the runtime is deliberately standard-library only; the optional [rag], [eval], [bdd] and [langchain] extras declare theirs). The development and CI toolchain is enumerated in requirements/.in and locked in requirements/.txt, which pin an exact version and every artifact's sha256 for the full transitive closure, enforced by pip --require-hashes. https://github.com/jonnyeclectic/boost/blob/main/pyproject.toml [osps_qa_02_01]

The project holds the line on dated idioms mechanically rather than by intention: ruff's pyupgrade (UP) family is enabled as a selected rule set with zero findings permitted, so a deprecated construct fails the build as it is written rather than accreting. The supported floor is Python 3.12+, which allowed the typing.List -> list and X | Y union sweeps to be completed rather than deferred. refurb additionally reports modernization smells the ruff families miss. Dependencies in the optional extras are tracked by Dependabot, so a deprecated upstream API surfaces as an upgrade pull request.

GitHub Actions runs the full gate on every push and every pull request: https://github.com/jonnyeclectic/boost/actions/workflows/ci.yml [test_continuous_integration] [osps_qa_06_01]

Well above 50%, and enforced rather than encouraged: a changed-line coverage gate requires at least 80% of the lines a pull request adds to be covered, and it is a required check. The mutation gate compounds it - 80% of mutants in boost_cli/core must be killed, so new logic that is executed but not asserted on still fails. Recent history bears it out; the most recent bug fix in this repository (a restored key fingerprint that a static-analysis autofix had deleted) shipped with a regression test verified to fail against the broken code and pass against the fix.

The coverage gate is set at exactly this threshold and is a required check: fail_under = 80 in the coverage configuration, run as part of make test over the unit and functional suites. A pull request that drops line coverage below 80% fails. The changed-line gate applies the same 80% to the diff specifically, so overall coverage cannot be held up by old code while new code arrives untested.

The policy is mandated by automation rather than by convention, which is the stronger form. CONTRIBUTING.md states that behaviour changes need tests and that anything under boost_cli/core is mutation-tested; the changed-line coverage gate and the mutation gate then enforce it as required status checks, so a change adding major functionality without tests cannot be merged into main even by the maintainer - main is protected and takes changes only through a pull request that has passed the full gate.

Documented in CONTRIBUTING.md ('The gates' table and 'Ground rules') and restated in the pull-request template checklist.

The gates are already maximally strict: zero tolerance on six linters and two type checkers, plus a complexity ratchet (xenon) that fails on regression rather than against an absolute threshold.

The principles from know_secure_design are implemented, not just understood, and https://github.com/jonnyeclectic/boost/blob/main/docs/security-design.md maps each to the code. Fail-safe defaults: archive members, path components and served skill names are accepted only against allowlists and rejected otherwise. Complete mediation: exactly one place asks whether a name may be joined onto a directory (util.is_safe_component) and one place joins a relative path inside a base; archive extraction validates a member's name and then discards it, rebuilding the destination from the basename, because a check that feeds its input forward is one refactor from being decorative. Least privilege: no elevation, no shell (shell=True appears nowhere), every subprocess an argument vector, and per-job CI permissions audited by zizmor. Economy of mechanism: a standard-library-only runtime enforced by import-linter, so there is no dependency tree to compromise.

Same evidence as crypto_working. Ed25519, SHA-2 and BLAKE2 have no known serious weakness, and nothing in the codebase depends on SHA-1 or CBC-mode SSH.

boost stores no authentication credential and no private cryptographic key. It performs signature VERIFICATION only, over public keys, and holds no secret of any kind: publishing to PyPI uses a short-lived OIDC identity minted per workflow run rather than a stored token, so there is nothing for the project to store separately, update or replace. Trusted public keys are held in their own state file rather than mixed into configuration, but a public key is not a credential in the sense this criterion means.

boost implements no network protocol of its own. Its network access is delegated entirely to git (for cloning tapped registries, over HTTPS or SSH) and to pip (for installation, over HTTPS); both use secure protocols by default and boost neither configures nor weakens them. No insecure protocol is supported or enabled anywhere, because no protocol is implemented at all.

boost does not implement or configure TLS. TLS is provided by git and by pip, which negotiate it themselves; boost passes no TLS options and cannot downgrade a version. The optional boost serve command binds a plain local HTTP listener for development on a trusted network and is documented as such rather than presented as a secure server.

boost does not implement TLS, so it performs no certificate verification of its own and cannot disable any. Certificate verification is done by git and pip with their defaults intact - boost passes no flag that would relax it, and there is no --insecure or verification-disabling option anywhere in the CLI.

boost does not implement TLS and sends no HTTP headers carrying private information. It has no accounts, no cookies, no session state and no authenticated requests of its own; all network transfer is delegated to git and pip.

Every release is signed with SLSA build provenance at build time. publish.yml runs actions/attest-build-provenance over dist/* after 'twine check' and before the PyPI upload, so the exact bytes published are the bytes signed, and the attestation records which workflow built which artifact from which commit. Upload to PyPI additionally uses Trusted Publishing (a short-lived OIDC identity, no stored token). A CycloneDX SBOM is generated per released wheel and attached to the GitHub release. Verification instructions: https://github.com/jonnyeclectic/boost/blob/main/docs/verifying-releases.md [osps_br_06_01]

Untrusted input is validated against allowlists and rejected, which is exactly the form this criterion asks for. The untrusted source is a tapped registry - a tap author controls the file paths, the frontmatter and the body, so all of it is attacker-controlled for modelling purposes. Concretely: util.is_safe_component accepts a path component only if it matches a restrictive allowlist pattern and is neither '.' nor '..', and it is the single place that question is asked; catalogbundle.safe_members accepts an archive member only if it is a regular file directly under catalog/ whose name is a plain basename, caps the member count, and then discards the member name and rebuilds the destination from the validated basename; serve.py accepts a skill name only against ^[A-Za-z0-9.-]+$ and joins paths only through _safe_join_within; workflows.py validates a Gemini agent name against a restrictive pattern before rendering. Where rejecting is not an option - the catalogue indexer must not fail the whole scan on one hostile entry - the unsafe name is rewritten by util.safe_component rather than passed through. The parsers are additionally fuzzed with atheris in CI.

Hardening mechanisms appropriate to a Python CLI are used. The largest is structural: the runtime imports no third-party package at all, enforced by import-linter, so there is no dependency tree in which a defect could become a vulnerability. Beyond that: no shell is ever invoked (shell=True appears nowhere; every subprocess call is an argument vector), tap clones are sparse and cone-limited so a registry's non-Markdown payload is never even fetched, installed content carries a sha256 tripwire that can be promoted from advisory to binding (core/integrity.py), and boost never requests elevated privileges. In CI, every workflow declares a read-only default token with write scopes granted per job, actions are pinned to commit SHAs, and step-security/harden-runner audits egress. The docs site is static with no scripts requiring a relaxed policy.

https://github.com/jonnyeclectic/boost/blob/main/docs/security-design.md is that assessment. It identifies the most likely and impactful problems for a CLI that clones third-party repositories and writes files into the directories an AI agent reads - path traversal via attacker-controlled frontmatter, command injection through skill and tap names, archive extraction escapes, link following, untrusted deserialization, supply-chain and CI-action compromise - and pairs each with the mitigation in the codebase. It also states the residual risks plainly, including the most important one: boost can give provenance, integrity and a diff, but cannot vet what a skill instructs an agent to do. [osps_sa_03_01]

CodeQL's Python security queries and ruff's flake8-bandit family are both vulnerability-focused rather than generic-defect tools, and osv-scanner plus pip-audit cover known-vulnerable dependencies.

Python is memory-safe, so there is no buffer overflow or use-after-free class for a tool such as ASan or Valgrind to find. The runtime has no C extension - the optional [rag] extra is not on the install path.