boost

CONTRIBUTING.md § Good first tasks names five standing starter tasks, each with the exact file to edit: add a registry to the catalog (scripts/build_registries.py), add a query to the retrieval golden set (tests/eval/golden.jsonl), teach the prose linter a word (.vale accept.txt), sharpen a command summary (COMMANDS in boost_cli/cli.py), and cover a branch nothing tests. They are standing rather than one-off on purpose, so a newcomer can start without waiting for an issue to be triaged; specific one-off tasks carry the good first issue label. https://github.com/jonnyeclectic/boost/blob/main/CONTRIBUTING.md#good-first-tasks

GitHub requires 2FA as of March 2023. [osps_ac_01_01]

The maintainer's second factor is a passkey — FIDO2/WebAuthn. The authenticator signs a challenge bound to the origin, so there is no shared secret to phish, replay or intercept, and it is not a plaintext channel the way SMS is. That is the strongest of the mechanisms this criterion accepts. Recorded in https://github.com/jonnyeclectic/boost/blob/main/docs/openssf-badge.md — which also notes that this answer was obtained by asking the maintainer rather than inferred from GitHub's 2FA mandate, since that mandate is satisfied by SMS.

https://github.com/jonnyeclectic/boost/blob/main/docs/code-review.md documents how review is conducted (the gate runs first, read the description as release notes, read the diff against the claim, look for the test that would have caught it, comment rather than silently fix), a table of what must be checked (layering, stdlib-only runtime, blast radius on $HOME, sparse checkouts, generated files, claims, security surface, tests, sign-off), and the six conditions that make a change acceptable. It opens by stating the single-maintainer shape rather than describing a review process the project does not have.

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

95.2% statement coverage of boost_cli, measured on the unit and functional suites alone — no smoke suite, no BDD suite — so the real figure is higher. It is enforced, not merely asserted: fail_under in pyproject.toml was raised from 80 to 90 in the same change, and coverage.py's blended statement+branch figure at that point was 94.04%. Green on ubuntu, macOS and Windows across Python 3.12, 3.13 and 3.14. https://github.com/jonnyeclectic/boost/blob/main/pyproject.toml

90.8% branch coverage, from that same run. branch = true is now set in [tool.coverage.run], which is what makes the number exist at all — before this change branch coverage had never been measured, so the figure could not be checked by anyone including the project. https://github.com/jonnyeclectic/boost/blob/main/pyproject.toml

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.

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]

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.

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.