Repo Blueprint

Only the latest release gets fixes, and the upgrade path is automatic: the blueprint bot of every repository runs copier update to each new release and opens a pull request, which merges once every check passes or shows its conflicts to the maintainer. A breaking change is a major version, whose notes say what to do. https://github.com/Dennis-Otto/repo-blueprint/blob/main/README.md#updates

GitHub Issues, with issue forms for bugs and feature requests: https://github.com/Dennis-Otto/repo-blueprint/issues

No vulnerability was reported or resolved in the last 12 months; the repository has no security advisory. SECURITY.md promises credit in the advisory and the release notes to every reporter who doesn't prefer anonymity. https://github.com/Dennis-Otto/repo-blueprint/blob/main/SECURITY.md#what-happens-next

SECURITY.md documents the process: private reporting through GitHub, acknowledgement within 7 days, a first assessment within 14 days, a fix of a confirmed vulnerability within 90 days at the latest, an update at least every 14 days when it takes longer, and disclosure in a GitHub security advisory and the release notes with credit for the reporter. https://github.com/Dennis-Otto/repo-blueprint/blob/main/SECURITY.md#what-happens-next

CONTRIBUTING.md names the style guides that contributions must follow: PEP 8 in the format of Ruff with the Ruff rules of pyproject.toml and strict mypy for Python, ShellCheck for shell scripts, actionlint and zizmor for workflows, markdownlint for Markdown and .editorconfig for every text file; and the same for every kind of project that the template creates. https://github.com/Dennis-Otto/repo-blueprint/blob/main/CONTRIBUTING.md#coding-standards

scripts/check.sh runs ruff format --check, ruff check and mypy --strict, the Lint workflow actionlint, markdownlint, REUSE and the DCO check, and zizmor audits the workflows; all are required checks of every pull request. Exceptions are rare and marked in the code with their reason.

The project produces no native binaries: the blueprint is a Copier template with Python scripts that run from source.

There is no compiled build: the blueprint is a Copier template with Python scripts that run from source.

There is no build system that builds subdirectories: the blueprint is a Copier template with Python scripts that run from source.

No building occurs: the release is the tagged commit of the template and the Python scripts, which run from source.

A repository installs the blueprint with copier copy gh:Dennis-Otto/repo-blueprint, the common way of Copier templates, and stays current with copier update; a repository leaves it by deleting .copier-answers.yml and the workflow blueprint-update.yml.

There is no POSIX installation step that writes to a chosen location: Copier decides where the files go.

CONTRIBUTING.md shows how to set up everything to make and test changes: a virtual environment and pip install --require-hashes -r requirements-dev.txt, then bash scripts/check.sh runs every check of the CI. The dev container in .devcontainer/ sets it up in one step for VS Code and GitHub Codespaces, and git config core.hooksPath .githooks runs the checks before every push. https://github.com/Dennis-Otto/repo-blueprint/blob/main/CONTRIBUTING.md#checks

The dependencies are listed in requirements-dev.in and pinned with hashes in requirements-dev.txt; those of every kind of project in the manifests and lock files of stacks/. https://github.com/Dennis-Otto/repo-blueprint/blob/main/requirements-dev.txt

Renovate updates the dependencies, an update that fixes a vulnerability at once; OSV-Scanner checks every lock file on every pull request and every week and reports to code scanning, where the Findings workflow keeps every finding fixed or accepted with a reason; the dependency review blocks pull requests that bring in a dependency with a known vulnerability. https://github.com/Dennis-Otto/repo-blueprint/blob/main/.github/workflows/osv-scanner.yml

Every dependency comes from a package manager, pinned in a lock file with hashes, and Renovate updates it; the repository holds no copy of third-party code.

Ruff's pyupgrade rules (UP) replace outdated Python constructs, pytest turns every warning, deprecations included, into an error (filterwarnings = error), and Renovate keeps actions and tools on current versions.

The CI runs scripts/check.sh, the whole test suite with its coverage gate, on every push to main and on every pull request, and reports success or failure as required checks; the Variants workflow renders every kind of project and runs its own checks with its real tools. https://github.com/Dennis-Otto/repo-blueprint/blob/main/.github/workflows/ci-python.yml

Of the 11 bugs fixed in the last six months, 5 brought a test in tests/ that fails without the fix, and 2 more are guarded by a required check that fails on the regression (zizmor for the pin of setup-php, REUSE for the license choice); the rest were fixes of the release workflows.

scripts/check.sh runs pytest under coverage.py, a FLOSS tool, and fails below 100 % of the lines and branches of blueprint.py and dashboard.py (fail_under = 100 in pyproject.toml). https://github.com/Dennis-Otto/repo-blueprint/blob/main/pyproject.toml

CONTRIBUTING.md has the written policy: new functionality comes with tests in the automated test suite, in the same pull request, and every fix with a test that fails without it; a pull request without the tests it needs is not merged. https://github.com/Dennis-Otto/repo-blueprint/blob/main/CONTRIBUTING.md#tests

The instructions for change proposals in CONTRIBUTING.md require tests for new functionality, and the checklist of the pull request template asks for them. https://github.com/Dennis-Otto/repo-blueprint/blob/main/CONTRIBUTING.md#tests

mypy runs in strict mode, Ruff with the rule sets E, F, W, I, B, UP, SIM, PT and RUF, and pytest with --strict-markers, --strict-config and every warning as an error.

The repository and its releases apply least privilege, fail-safe defaults, complete mediation, separation of privilege, least common mechanism, economy of mechanism, open design and psychological acceptability, as the assurance case of SECURITY.md shows; docs/security.md shows the secure design of the software: no code runs when a repository is copied, blueprint.py never handles the value of a secret, every update is a pull request that passes the checks of each repository. https://github.com/Dennis-Otto/repo-blueprint/blob/main/docs/security.md

The blueprint implements no security mechanism with its own cryptography; releases are signed by Sigstore and GitHub with SHA-256 digests.

The software implements no cryptographic algorithm of its own; TLS comes from the GitHub CLI and Python's standard library, which verify certificates by default, and the signatures of releases from Sigstore.

The blueprint stores no credentials. The secrets of a repository live in its GitHub environments, separate from every file, and are replaced with gh secret set without any change of code; blueprint.py only names the missing ones.

Every connection goes to GitHub through the GitHub CLI over HTTPS.

The GitHub CLI uses TLS 1.2 or later, as GitHub requires.

The GitHub CLI verifies TLS certificates by default, and the blueprint never turns that off.

TLS certificates are verified in the handshake, before any HTTP header with a token is sent; TLS comes from the GitHub CLI and Python's standard library, which verify certificates by default, and the signatures of releases from Sigstore.

Releases are immutable; GitHub signs an attestation that ties each tag to its commit and files, and the release workflow signs the build provenance of every file with Sigstore, without a long-lived key. SECURITY.md documents how users verify a release with gh release verify. https://github.com/Dennis-Otto/repo-blueprint/blob/main/SECURITY.md#verify-a-release

Every release tag since v0.6.0 is an annotated tag that the release workflow signs without a key with gitsign: Sigstore certifies the identity of the release workflow, and the release check verifies the signature and that identity after every release and every week. https://github.com/Dennis-Otto/repo-blueprint/blob/main/.github/sign-tag.sh https://github.com/Dennis-Otto/repo-blueprint/releases/tag/v0.6.0

The answers of the Copier questions pass their validators (allowlists such as ^[a-z0-9][a-z0-9-]*[a-z0-9]$ for names); blueprint.py reads every answer of GitHub strictly and stops on anything else, which coverage-guided fuzzing with Atheris checks. https://github.com/Dennis-Otto/repo-blueprint/blob/main/docs/security.md#trust-boundaries

Every workflow starts without permissions, pins every action by commit hash (a setting of the repository), checks out without persisting credentials, runs under Harden-Runner, and keeps secrets in environments that only main can use.

SECURITY.md has the assurance case of the repository and its releases: the threat model, the trust boundaries, the secure design principles and how the OWASP Top 10 CI/CD security risks are countered, with CodeQL for the CWE Top 25. docs/security.md completes it for the blueprint itself: what it protects, its trust boundaries, its threats with countermeasures and tests, and the residual risks. https://github.com/Dennis-Otto/repo-blueprint/blob/main/SECURITY.md#assurance-case https://github.com/Dennis-Otto/repo-blueprint/blob/main/docs/security.md

CodeQL with its security-extended queries analyzes the Python and the workflows on every pull request and every push to main; zizmor audits the workflows for their known attack patterns.

The project has no code in a memory-unsafe language: Python, Jinja templates, shell scripts and YAML.