bitmath

Every workflow in .github/workflows/ declares permissions: read-all at the top level, so any task without an explicit permission block runs read-only. Elevated permissions (security-events: write, id-token: write) are scoped to specific jobs only where required. Verifiable at https://github.com/timlnx/bitmath/tree/master/.github/workflows

Releases follow Semantic Versioning. The single source of truth is the VERSION file (https://github.com/timlnx/bitmath/blob/master/VERSION), which pyproject.toml reads dynamically via [tool.hatch.version]. Each release is tagged in git and published to PyPI under its SemVer identifier: https://github.com/timlnx/bitmath/releases

Every release has a corresponding section in NEWS.rst (https://github.com/timlnx/bitmath/blob/master/NEWS.rst) describing functional changes, breaking changes, and security-relevant modifications in human-readable prose well beyond commit-message granularity. The same content is also published to GitHub Releases: https://github.com/timlnx/bitmath/releases

Dependencies are managed through the standard Python packaging stack: pyproject.toml declares build and project metadata per PEP 517/518/621 (https://github.com/timlnx/bitmath/blob/master/pyproject.toml), Hatchling is the build backend, and requirements.txt (https://github.com/timlnx/bitmath/blob/master/requirements.txt) pins the development dependency set. Runtime dependencies are intentionally zero.

Releases are published to PyPI via PyPI Trusted Publishing (OIDC), which produces sigstore-backed PEP 740 attestations attached to every artifact. PyPI also publishes a SHA-256 hash for each released file. The publish workflow is at https://github.com/timlnx/bitmath/blob/master/.github/workflows/publish.yml and trust-publisher metadata is visible on the PyPI project page: https://pypi.org/project/bitmath/

The "Components" section of the contributing guide (https://bitmath.readthedocs.io/en/latest/contributing.html#components) enumerates every development dependency with its purpose and rationale. The zero-runtime-dependency policy and the use of pyproject.toml + requirements.txt for tracking are documented in CLAUDE.md (https://github.com/timlnx/bitmath/blob/master/CLAUDE.md) and visible in pyproject.toml directly.

The contributing guide's "Makefile Targets" section (https://bitmath.readthedocs.io/en/latest/contributing.html#makefile-targets) documents make ci, make build, make docs, and make clean, including their behavior and when to use each. The README also includes a quick-start. The Makefile itself (https://github.com/timlnx/bitmath/blob/master/Makefile) is the authoritative build automation.

MAINTAINERS.md (https://github.com/timlnx/bitmath/blob/master/MAINTAINERS.md) lists the current maintainer (Tim Case / @timlnx) and explicitly enumerates every sensitive resource that person has access to: the GitHub repository (admin), the PyPI project (via OIDC), the Read The Docs project, and the security-reporting email address.

MAINTAINERS.md (https://github.com/timlnx/bitmath/blob/master/MAINTAINERS.md) describes the maintainer role, responsibilities (PR review, releases, security triage, Code of Conduct enforcement, dependency surface oversight), the decision-making process, and a standing open request for a Debian/Ubuntu co-maintainer (tracked in https://github.com/timlnx/bitmath/issues/117).

The contributing guide (https://bitmath.readthedocs.io/en/latest/contributing.html) documents the requirements for acceptable contributions including: code style (pycodestyle PEP 8 + pylint 10.00/10 target), commit message conventions, the pull request workflow with required CI status checks, testing expectations (unit tests for new functionality), the supported Python version policy, and the Makefile targets contributors should run locally before submitting.

bitmath is hosted on GitHub. Per the GitHub Terms of Service, §D.6 "Contributions Under Repository License," every contributor pushing to a public repository licenses their contribution under the repository's license by the act of pushing. The OSPS criterion text itself acknowledges: "Some version control systems, such as GitHub, may include this in the platform terms of service." This control is satisfied via that mechanism.

Branch protection on master requires 17 status checks to pass before any commit can be merged: the full Python 3.9–3.13 × {macOS, Ubuntu, Windows} test matrix plus CodeQL and Bandit. enforce_admins: true so even the repo owner cannot bypass these checks.

The .github/workflows/python.yml workflow (https://github.com/timlnx/bitmath/blob/master/.github/workflows/python.yml) runs the full pytest suite on every push and pull request, across Python 3.9, 3.10, 3.11, 3.12, and 3.13 on macOS, Ubuntu, and Windows. Test results are publicly visible on every PR, and the same tests can be run locally via make ci.

ARCHITECTURE.md (https://github.com/timlnx/bitmath/blob/master/ARCHITECTURE.md) at the repository root documents the system as actors and actions across two scopes: the runtime library (user code → public API → class hierarchy → OS abstraction layer) and the build/release pipeline (PyPI flow plus the parallel Packit-driven Fedora/EPEL RPM flow). The Maintenance section establishes an update contract tied to public API, build pipeline, and trust boundary changes, with review at every minor release.

Every public class, method, and module-level function in bitmath has reference documentation at https://bitmath.readthedocs.io/ covering inputs, outputs, exceptions, and usage examples. The documentation source is in docsite/source/ and is regenerated from the codebase on every release.

SECURITY_ASSESSMENT.md (https://github.com/timlnx/bitmath/blob/master/SECURITY_ASSESSMENT.md) is a standing threat model that describes: what bitmath does and deliberately does not do (no network, no eval, no subprocess, zero runtime dependencies); the realistic attack surfaces ranked by concern (parse_string, filesystem helpers, query_device_capacity, the build/release pipeline); the mitigations in place for each; and the automated security tooling continuously assessing the project (Bandit, CodeQL, OSSF Scorecard, Dependabot, GitHub secret scanning). It is committed to revisit at every minor release.

SECURITY.md (https://github.com/timlnx/bitmath/blob/master/SECURITY.md) documents the coordinated vulnerability disclosure process with explicit response timeframes: acknowledgement of receipt within 72 hours, initial triage assessment within 7 days, and coordinated disclosure synchronized with the patch release that contains the fix. Backup contact channels are provided in case the primary email path fails.

Two private reporting channels are available, both documented in SECURITY.md (https://github.com/timlnx/bitmath/blob/master/SECURITY.md): GitHub's native Private Vulnerability Reporting (enabled on the repository, accessible via the Security tab), and direct email to bitmath@lnx.cx. Bluesky and Instagram are listed as emergency backup channels if both primary methods fail.

The project publishes vulnerability information through GitHub Security Advisories (https://github.com/timlnx/bitmath/security/advisories) with CVE numbers when applicable, and through the relevant version's section in NEWS.rst. As of submission, zero vulnerabilities have been reported or confirmed against bitmath, so no advisories exist yet, but the publication channel is configured and operational.