boost

Public repository with full history: https://github.com/jonnyeclectic/boost

git. Every change is a tracked commit with author and message, and main is protected: changes land only through a pull request that has passed the full required-check gate. (Note what is not claimed: the ruleset deliberately does not require a human approval, because the working model is parallel loop/* branches that self-merge. The criterion asks for tracked changes, not review.)

Interim versions are on main continuously, and the release cadence is per merge, so the published version is never more than one merge behind the repository.

git.

Versions come from setuptools-scm reading git tags, so there is no hand-maintained version constant to fall out of sync and a version is unique by construction. 'boost --version' reports it.

Semantic versioning, vMAJOR.MINOR.PATCH (current series v1.2.x).

Every release is a git tag created by the release workflow: https://github.com/jonnyeclectic/boost/tags

https://github.com/jonnyeclectic/boost/releases - one GitHub release per version, with notes assembled by release-drafter from the merged pull-request titles. CONTRIBUTING asks contributors to write the PR description as the release note for exactly this reason.

No publicly known run-time vulnerability in boost itself has ever been reported, assigned a CVE, or fixed, so no release has had one to name. The forward policy is written down at https://github.com/jonnyeclectic/boost/blob/main/SECURITY.md - any release fixing a publicly known vulnerability will name it and its identifier in the release notes. This will be re-answered as Met at the first such release.

https://github.com/jonnyeclectic/boost/issues/new/choose - issue templates for bug reports and feature requests (.github/ISSUE_TEMPLATE/bug_report.yml and feature_request.yml). CONTRIBUTING points at the tracker.

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

The maintainer triages issues as they arrive and the majority of the issue history is resolved rather than left open. CI failures on main are additionally opened as issues automatically by .github/workflows/ci-failure-issue.yml and closed on the fix.

Enhancement requests are answered, and those accepted are tracked as cards on the public roadmap at https://jonnyeclectic.github.io/boost/docs/roadmap.html

https://github.com/jonnyeclectic/boost/issues?q=is%3Aissue - the full history, open and closed, publicly readable without an account.

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

GitHub private vulnerability reporting is enabled on the repository. Reports go to https://github.com/jonnyeclectic/boost/security/advisories/new and never to a public issue; SECURITY.md says so explicitly.

No vulnerability report has been received in the last six months - none has been received at all. SECURITY.md commits to an acknowledgement within a few days, well inside the criterion's 14-day bound.

Standard PEP 517 build from pyproject.toml ('python -m build'), exercised end to end by the release workflow, which builds the wheel and smoke-tests it before publishing. 'make venv' reproduces a development environment from hash-pinned requirements.

setuptools plus the standard 'build' frontend, driven by make and by noxfile.py.

Every build and gate tool is FLOSS and runs on FLOSS platforms; CI runs on Ubuntu as well as macOS and Windows.

Four tiers: tests/unit and tests/functional (pytest; the functional suite drives the real CLI in-process), tests/smoke.sh (170 end-to-end checks through the ./boost shim), and a Gherkin BDD suite of 11 features / 47 scenarios.

'make test'. Alternatively 'nox', which reproduces the exact CI gate in isolated venvs across every supported interpreter, so green locally and green in CI mean the same thing.

An 80% line-coverage gate (fail_under = 80), an 80% changed-line coverage gate on pull requests, and an 80% mutation-testing gate over boost_cli/core. The last means coverage cannot be satisfied by tests that merely execute code without asserting on it.

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

CONTRIBUTING.md states it outright: 'Behavior changes need tests', and 'Anything under boost_cli/core/ is mutation-tested; expect to add unit tests that actually kill your mutants.'

The policy is mechanically enforced rather than merely stated. The changed-line coverage gate fails a pull request whose new lines are under 80% covered, and the mutation gate fails one whose new core/ logic is untested, because an unexercised branch counts as an unkilled mutant. Both are required checks, so a change adding functionality without tests cannot merge.

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

Python has no compiler warnings, so this is met by linters, all of which are required checks: ruff (with an explicit rule set including the S/flake8-bandit, B/bugbear, SIM, C4, PERF, RUF, UP and I families), mypy, pyright, vulture, xenon and refurb. pytest additionally promotes DeprecationWarning raised inside boost_cli to a hard error.

Not 'mostly fixed' - zero findings are permitted. Each tool above is a required check that fails the build on a single finding, so warnings cannot accumulate. ruff's rule set is spelled out with 'select' rather than 'extend-select', so a tool upgrade can never silently switch rule families on or off.

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.

https://github.com/jonnyeclectic/boost/blob/main/docs/security-design.md is the project's written threat model. It names boost's trust boundaries (a tap author is treated as an attacker for modelling purposes) and works through Saltzer and Schroeder's eight principles - economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability - as concrete claims about this codebase, each pointing at the code that implements it.

The same document carries a table of the CWE/OWASP error classes that apply to a CLI that clones repositories and writes files - path traversal (CWE-22), OS command injection (CWE-78), archive extraction / zip-slip, link following (CWE-59), untrusted deserialization (CWE-502), supply-chain and CI-action compromise (CWE-1357, CWE-829), leaked credentials (CWE-798), insecure download (CWE-494/319) and improper input validation (CWE-20) - each paired with the specific mitigation in the repository that counters it. Classes that do not apply (SQL injection, XSS) are omitted rather than padded.

boost verifies minisign/Ed25519 signatures over tap content. The algorithms used are Ed25519 (RFC 8032), SHA-512 and SHA-256 (FIPS 180-4) and BLAKE2b-512 (RFC 7693) - all publicly published and reviewed by experts. No private or proprietary algorithm is used anywhere.

Everything cryptographic is Python's standard-library hashlib plus boost's own GPL-3.0 code. There is no proprietary component and every function is implementable using FLOSS.

Ed25519 is a 255-bit curve, above the criterion's 224-bit elliptic-curve minimum, and the digests used are 256- and 512-bit, above the 224-bit hash minimum. No shorter keylength is configurable, so there is nothing to disable.

No MD4, MD5, SHA-1, single DES, RC4, Dual_EC_DRBG or ECB mode appears anywhere in the codebase. ruff's S (flake8-bandit) family fails the build on weak-hash use, so a regression is caught mechanically rather than by review.

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 implements no key-agreement protocol and no network cryptography, so there is no session key to protect. TLS is provided by git and by pip, not by boost.

boost performs no inbound authentication of external users and stores no password. It is a local command-line tool with no accounts and no server.

boost generates no cryptographic key and no nonce - signing is the publisher's job and boost only verifies. The 'random' module is imported nowhere in boost_cli/, so there is no insecure generator that could be substituted for a secure one.

Distribution is PyPI over HTTPS ('pipx install boost-skill-cli') and GitHub over HTTPS. Publishing uses PyPI Trusted Publishing - a short-lived OIDC identity minted for the publish workflow specifically, with no long-lived token stored anywhere - and each release carries a SLSA build-provenance attestation tying the artifact to the commit and workflow that produced it. Taps are cloned over HTTPS or SSH.

boost consumes no cryptographic hash fetched over HTTP. The only hashes in the build are the sha256 values committed in requirements/*.txt, which pip enforces with --require-hashes over an HTTPS connection, and the tool downloads in CI are HTTPS at a pinned version.

There are no unpatched vulnerabilities of medium or higher severity, publicly known or otherwise - none has been reported against boost. Dependency exposure is watched continuously by osv-scanner, pip-audit and Dependabot, all of which run in CI, and the runtime has no third-party dependency to inherit one from.

Same position: none has been reported. The release cadence of one release per merge means a fix would reach users within minutes of landing rather than waiting for a release train.

gitleaks runs in CI on every push over the repository and fails the build on a hit; the allowlist in .gitleaks.toml covers only boost's own synthetic secret-scanner test fixtures. Structurally there is little to leak in the first place: publishing uses a short-lived OIDC identity rather than a stored PyPI token, and the two optional dashboard secrets are absent by default with their jobs skipping themselves.

Several tools, all required checks, all run before every release - which is every merge to main. CodeQL does semantic analysis on push, on pull request and weekly (https://github.com/jonnyeclectic/boost/blob/main/.github/workflows/codeql.yml). ruff's S/flake8-bandit family is Python SAST covering shell=True, tempfile.mktemp, unsafe YAML loading and weak hashing. mypy and pyright are two independent type checkers, the second adding None-flow and narrowing analysis over core/. zizmor audits the GitHub Actions workflows for excessive permissions and unpinned action refs. import-linter enforces the architectural layering. SonarCloud is additionally wired up as an optional, non-blocking dashboard.

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.

Findings are fixed, or dismissed with a written proof of why they are false positives - never dismissed for convenience. The project keeps that discipline recorded publicly on its roadmap, including the explicit rule that supply-chain posture metrics must not be filed as false positives just to clear the inbox.

Every push and every pull request, plus a weekly scheduled CodeQL run so new query releases are applied to unchanged code.

https://github.com/jonnyeclectic/boost/blob/main/.github/workflows/fuzz.yml runs atheris (libFuzzer for Python) against the parsers over a target matrix, uploading any crashing input as an artifact. Beyond fuzzing, tests/smoke.sh drives the real binary end to end through 170 checks and the functional suite executes the CLI against a throwaway HOME.

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.

The test suites are assertion-driven and run with assertions enabled (never with -O), and pytest promotes DeprecationWarning raised inside boost_cli to a hard error, so a latent deprecation fails a run rather than scrolling past in the log.

No medium-or-higher severity exploitable vulnerability has been found by dynamic analysis. A crashing input found by the fuzzer is uploaded as a workflow artifact and fixed; none is outstanding.