gpumesh

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Development happens on feature branches merged into master via pull request, and every interim commit is publicly visible at https://github.com/K4-LABS/gpumesh/commits/master -- the repository is not a series of release drops.

Repository on GitHub, which uses git. git is distributed.

Every release carries a unique semantic version, declared in pyproject.toml and exposed as gpumesh.version. It is also reported by gpumesh --version.

Semantic Versioning is used. See https://github.com/K4-LABS/gpumesh/blob/master/CHANGELOG.md

Releases are identified with git tags, e.g. v3.0.0. https://github.com/K4-LABS/gpumesh/tags

Non-trivial release notes file in repository: https://github.com/K4-LABS/gpumesh/blob/master/CHANGELOG.md.

gpumesh has had no publicly known vulnerabilities with a CVE assignment or similar, so there are none for any release to identify.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/K4-LABS/gpumesh/blob/master/SECURITY.md. [osps_do_02_01]

GitHub Issues is the bug tracker: https://github.com/K4-LABS/gpumesh/issues , with structured templates at https://github.com/K4-LABS/gpumesh/tree/master/.github/ISSUE_TEMPLATE

GitHub Issues and Pull Requests are publicly readable, permanently archived and full-text searchable, and each report and its responses are addressable by URL. https://github.com/K4-LABS/gpumesh/issues?q=is%3Aissue

https://github.com/K4-LABS/gpumesh/blob/master/SECURITY.md publishes the process: report privately through GitHub Security Advisories at https://github.com/K4-LABS/gpumesh/security/advisories/new (the "Report a vulnerability" button on the Security tab), do not open a public issue, with an email fallback for anyone who cannot use advisories. It also states what to include, acknowledgement within 3 business days, initial assessment within 14 days, a fix or documented mitigation plan within 60 days for medium severity and above, and a safe-harbour statement.

https://github.com/K4-LABS/gpumesh/blob/master/SECURITY.md instructs reporters to use GitHub Security Advisories (https://github.com/K4-LABS/gpumesh/security/advisories/new), which is a private channel, and explicitly says not to open a public issue. An email fallback is also given.

No vulnerability reports have been received in the last 6 months, so there is no response time to measure. The published targets in SECURITY.md are acknowledgement within 3 business days and initial assessment within 14 days.

Per SECURITY-INSIGHTS.yml: repository.release.automated-pipeline=true

The project builds with standard Python packaging tooling: python -m build against a PEP 621 pyproject.toml, producing a wheel and sdist. The container image builds with a standard Dockerfile.

All build tooling is FLOSS: CPython, setuptools, build, and Docker/BuildKit. No proprietary tool is required at any point.

An automated test suite of well over a thousand tests lives at https://github.com/K4-LABS/gpumesh/tree/master/tests and is run by https://github.com/K4-LABS/gpumesh/blob/master/.github/workflows/tests.yml

A single command runs the whole suite: pytest. Documented in the "Tests" section of https://github.com/K4-LABS/gpumesh/blob/master/CONTRIBUTING.md

The suite covers the externally visible functionality: CLI argument parsing and commands, the coordinator HTTP API, worker registration and task execution, the SQLite job store and leases, serialization and result envelopes, authentication and rate limiting, discovery, and the claim protocol. See https://github.com/K4-LABS/gpumesh/tree/master/tests

https://github.com/K4-LABS/gpumesh/blob/master/.github/workflows/tests.yml runs the full suite on every push and every pull request, across multiple Python versions and operating systems.

https://github.com/K4-LABS/gpumesh/blob/master/CONTRIBUTING.md states the policy directly: "Every behavioural change needs a test", and documents the test conventions that a new test is expected to follow.

The policy in https://github.com/K4-LABS/gpumesh/blob/master/CONTRIBUTING.md is "Every behavioural change needs a test", and recent changes follow it. The most recent major change (the 3.2.0 security work: PBKDF2 token derivation, opt-in TLS, and strict result deserialization) shipped with 189 new tests across tests/test_security.py, tests/test_tls.py, tests/test_serializer.py and tests/test_client.py. The pull request template at https://github.com/K4-LABS/gpumesh/blob/master/.github/pull_request_template.md asks for the same.

The requirement to add tests for new functionality is documented in the "Tests" section of https://github.com/K4-LABS/gpumesh/blob/master/CONTRIBUTING.md and repeated in the pull request template at https://github.com/K4-LABS/gpumesh/blob/master/.github/pull_request_template.md

ruff runs on every pull request via https://github.com/K4-LABS/gpumesh/blob/master/.github/workflows/tests.yml , and mypy runs alongside it. ruff is also a pre-commit hook: https://github.com/K4-LABS/gpumesh/blob/master/.pre-commit-config.yaml

Warnings are addressed on a deliberate two-tier split, documented in https://github.com/K4-LABS/gpumesh/blob/master/.github/workflows/tests.yml . Tier 1, the hard gate: ruff runs with --select E9,F63,F7,F82 -- undefined names, syntax errors, and the checks that are never a style opinion and always a bug at runtime. This reports zero, is a required check, and fails the build if it ever stops reporting zero. Tier 2, advisory: the full ruleset from [tool.ruff.lint] in pyproject.toml runs on every pull request and annotates findings inline in the diff, where they are actually read. It carries a backlog inherited from before the ruff configuration existed, so it is currently marked continue-on-error; the workflow states in a comment that the intended end state is removing that, once the backlog is burned down. The backlog is majority cosmetic -- blank lines containing whitespace, import ordering, and unused imports account for most of it. Security findings get their own step and their own treatment: ruff --select S runs separately, because this project deserializes callables received over a socket, and each finding is expected to be resolved by a code change or by an explicit "# noqa: S### - reason" comment recording a human decision rather than a silent pass. Beyond the linter, CodeQL runs the security-and-quality suite on every push, pull request and weekly, and pip-audit does the same for dependency advisories. Warnings from those are triaged rather than accumulated. The formatter question is decided deliberately rather than by neglect: https://github.com/K4-LABS/gpumesh/blob/master/.pre-commit-config.yaml explains at the top that no auto-formatter runs over this repository, because a formatting sweep would touch nearly every file and turn every open branch into a merge conflict.

https://github.com/K4-LABS/gpumesh/blob/master/THREAT_MODEL.md is a maintainer-authored threat model with a STRIDE table, trust boundaries, and every claim carrying a file:line citation. https://github.com/K4-LABS/gpumesh/blob/master/SECURITY.md states the granted capabilities and the trust domain explicitly, including that a valid token is a licence to execute code rather than a password guarding data.

The threat model and security policy address the error classes that apply to this design: deserialization of untrusted data in both directions, authentication bypass and timing side channels (hmac.compare_digest), brute force (per-IP rate limiting), path traversal, and unintended network exposure (loopback-by-default bind with an exposure banner). https://github.com/K4-LABS/gpumesh/blob/master/THREAT_MODEL.md

Only published, standard algorithms are used: SHA-256 and HMAC-SHA256, via the Python standard library hashlib and hmac modules.

The project implements no cryptography of its own. It calls the Python standard library (hashlib, hmac, secrets), which is backed by OpenSSL.

All cryptographic functionality comes from the Python standard library and OpenSSL, both FLOSS.

All default key and digest lengths meet or exceed the NIST minimums through 2030. Token hashes are derived with PBKDF2-HMAC-SHA256 (256-bit digest, 200000 iterations by default) and compared with HMAC-SHA256. TLS certificates generated by the coordinator use RSA-2048, and the TLS floor is 1.2 on both the server and the client. Tokens are generated with secrets.token_urlsafe(); the README recommends secrets.token_urlsafe(32) for any mesh reachable beyond loopback, and any length can be supplied via --token or GPUMESH_TOKEN.

No broken or obsolete algorithm is used. There is no MD5, no SHA-1, and no DES anywhere in the codebase; token digests are SHA-256 and comparisons go through hmac.compare_digest.

The default cryptographic primitives are SHA-256 and HMAC-SHA256. Algorithms with known serious weaknesses (MD5, SHA-1) are not used, by default or otherwise.

The coordinator's TLS listener is built on ssl.SSLContext with a TLS 1.2 minimum on both ends (https://github.com/K4-LABS/gpumesh/blob/master/gpumesh/tls.py). Python's default cipher suite selection at TLS 1.2 and above prefers ECDHE key agreement, and TLS 1.3 mandates it, so session keys are forward-secret: compromising the coordinator's long-term private key does not expose recorded past sessions. Static-RSA key exchange is not offered. Note that TLS is opt-in (gpumesh serve --tls) and plain HTTP remains the default, which is documented as LAN-only in https://github.com/K4-LABS/gpumesh/blob/master/SECURITY.md .

gpumesh does not store passwords for the authentication of external users. It has no user accounts and no password database. Authentication is a single shared bearer token that the operator generates and distributes; the coordinator holds only a PBKDF2-HMAC-SHA256 hash of it, in memory, and never writes it to the database.

Security-relevant random values are generated with the Python secrets module, which is the standard cryptographically secure source. Tokens are produced by secrets.token_urlsafe().

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Nothing is retrieved over plain http. The package is installed from PyPI over HTTPS with hashes verified by pip, the container image is pulled from Docker Hub over HTTPS with content digests, and the release pipeline publishes to PyPI via Trusted Publishing (OIDC) rather than a long-lived credential. Every GitHub Actions dependency in https://github.com/K4-LABS/gpumesh/tree/master/.github/workflows is pinned to a full commit SHA rather than a mutable tag, specifically so a retagged action cannot substitute different code.

There are no unpatched vulnerabilities of medium or higher severity in gpumesh. No vulnerability has been publicly disclosed against the project to date, so none has gone unpatched for any length of time. Dependency vulnerabilities are watched continuously by pip-audit and Dependabot, both configured to run weekly in addition to on every pull request.

No critical vulnerability has been reported against gpumesh to date, so none has gone unfixed. The published commitment in SECURITY.md is acknowledgement within 3 business days, initial assessment within 14 days, and a fix or documented mitigation plan within 60 days for medium severity and above; critical reports are handled ahead of that schedule.

Per SECURITY-INSIGHTS.yml: repository.security.tools type=secret Comment says: ".pre-commit-config.yaml. Scans the staged diff for
credential-shaped strings, alongside pre-commit-hooks'
detect-private-key.

Note the honest split, because it matters for what this entry
claims: gitleaks runs on a contributor's machine, at git commit,
against staged files. It is deliberately SKIPped in CI
(.github/workflows/hygiene.yml) because its entry is
gitleaks ... --staged, and a CI checkout has nothing staged, so
it would inspect nothing and pass — a green check that proves
nothing is worse than no check. ci: false below is therefore
accurate rather than an omission. What DOES gate every pull request
is detect-private-key and check-added-large-files, in the same
hygiene workflow; those exist because this repository keeps
gitignored operator notes carrying a live coordinator token, and a
.gitignore stops git add . and stops nothing else.".

Per SECURITY-INSIGHTS.yml: repository.security.tools type=SAST Comment says: ".github/workflows/codeql.yml, security-and-quality query suite.
Runs on every push to master, every pull request, and weekly.
Results land in the repository's code-scanning dashboard. This is
the analysis that models data flow across modules, which is what
matters in a codebase whose central operation is unpickling a
callable that arrived over a socket.".

CodeQL runs with the security-and-quality query suite, which covers the common vulnerability classes for Python: https://github.com/K4-LABS/gpumesh/blob/master/.github/workflows/codeql.yml . ruff's flake8-bandit (S) rules are also selected, deliberately, because this project deserializes callables received over a socket.

CodeQL runs on every push to master, on every pull request, and weekly: https://github.com/K4-LABS/gpumesh/blob/master/.github/workflows/codeql.yml . pip-audit runs on the same cadence: https://github.com/K4-LABS/gpumesh/blob/master/.github/workflows/pip-audit.yml

gpumesh is written entirely in Python, a memory-safe language. There is no code in a memory-unsafe language in the software the project produces, so memory-safety dynamic analysis does not apply.