boost

GitHub requires 2FA as of March 2023.

GitHub, the project's version control system, requires an explicit permission level to be chosen when a collaborator is invited - there is no implicit grant, and the default offered is Read. No collaborator receives write access without a deliberate assignment.

A direct commit to main is refused. The repository carries both classic branch protection (main reports protected: true with 14 required status checks) and a ruleset containing a pull_request rule, so a change can only reach main through a pull request that has passed the required-check gate. A non_fast_forward rule additionally blocks force-pushes. CONTRIBUTING.md documents the same policy: https://github.com/jonnyeclectic/boost/blob/main/CONTRIBUTING.md

main is a protected branch in GitHub. A protected branch cannot be deleted through the UI or the API while its protection is in place - the protection must first be explicitly removed - which is a stronger guarantee than a confirmation prompt. A non_fast_forward ruleset rule also prevents history from being rewritten.

The CI workflows are statically audited by zizmor on every pull request as a required check ('workflow SAST (zizmor)' in ci.yml), and template injection is one of the classes it flags - untrusted metadata such as a branch name, commit message, tag, pull-request title or author interpolated directly into a run: block. The workflows are written to that rule deliberately: where such a value is needed it is passed through an env: binding rather than interpolated into the shell, and adapter-conformance.yml carries an explicit comment naming the template-injection shape it is avoiding.

No workflow in the repository uses pull_request_target - every pull-request job runs on the pull_request event, so a fork's proposed code executes with a read-only GITHUB_TOKEN and no access to repository secrets. The few secrets referenced (CODECOV_TOKEN, SONAR_TOKEN, and the optional evaluation API keys) resolve to empty for a fork pull request, and each guarded step skips itself rather than failing. Publishing credentials are not stored at all: releases use PyPI Trusted Publishing, a short-lived OIDC identity minted only for the publish workflow, which never runs on a pull request. step-security/harden-runner additionally audits egress on the sensitive jobs.

Project URLs use HTTPS exclusively.

Distribution channels use HTTPS exclusively.

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. [no_leaked_credentials]

README (install, quick start, concepts), the Visual Guide at https://jonnyeclectic.github.io/boost/, docs/DEBUGGING.md and docs/rag-architecture.md. [documentation_basics]

Non-trivial SECURITY[.md] file found file in repository: https://github.com/jonnyeclectic/boost/blob/main/SECURITY.md.

GitHub supports public discussions on proposed changes (via pull requests) and usage obstacles (via issues).

Contribution process documented in repository.

The GPL-3.0 license for the repository contents is approved by the Open Source Initiative (OSI).

GPL-3.0. [floss_license]

License file found in repository.

https://github.com/jonnyeclectic/boost/blob/main/LICENSE - at the repository root, and declared in pyproject.toml. [license_location]

Repository is publicly available on GitHub.

Repository git metadata is publicly available on GitHub.

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

boost is a single-repository project. There are no subproject repositories that are part of the project or compiled into a release; everything released as boost-skill-cli is built from https://github.com/jonnyeclectic/boost alone.

The repository contains no generated executable artifact. The files carrying the executable bit are all reviewable source - shell scripts under scripts/ and examples/, Python scripts under scripts/, evals/ and tests/, and the ./boost development shim. Build outputs (wheel, sdist) are produced at release time by the publish workflow and are never committed; boost_cli/_version.py is generated by setuptools-scm at build time and is gitignored.

The repository contains no unreviewable binary artifact - no application binary, no library file, no compiled object. An audit of every tracked file for binary content returns only reviewable items: three zero-byte marker files (two package init.py files and boost_langchain/py.typed) and a handful of fuzzing corpus seeds under tests/fuzz/corpus/, the largest of which is 10 bytes and which exist precisely to be read as byte sequences (one contains a NUL to seed that input class). The remaining binary-format files are documentation assets - the demo GIF and site images - which the criterion explicitly excludes.

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]