cpace

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.

The project uses Git as its version control system on GitHub. The repository contains the full commit history (dozens of commits) with many interim versions between releases, enabling collaborative review through pull requests and commit history. It does not contain only final releases.

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

Official releases are created using Git tags with unique version identifiers following semantic versioning (e.g. v0.1.0, v0.2.0). Each release is documented in CHANGELOG.md and follows the release process defined in docs/release-checklist.md.
https://github.com/the-sarge/cpace/tags
https://github.com/the-sarge/cpace/blob/main/CHANGELOG.md [osps_br_02_01]

The project identifies each release within its Git version control system using Git tags (e.g., v0.1.0, v0.2.0).

Non-trivial release notes file in repository: https://github.com/the-sarge/cpace/blob/main/CHANGELOG.md.

The project is currently in draft stage (v0.x range) and has not had any publicly known vulnerabilities with CVE assignments. As such, there are no vulnerabilities to identify in release notes. This criterion is marked N/A.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/the-sarge/cpace/blob/main/SECURITY.md. [osps_do_02_01]

The project uses GitHub Issues as its issue tracker for tracking bugs, enhancements, and other individual issues.

The project acknowledges the majority of bug reports submitted via GitHub Issues. As an actively maintained project, the maintainer responds to reports in a timely manner. Given the current low volume of issues, the majority of reports receive a response.

The project responds to the majority of enhancement requests submitted via GitHub Issues. As an actively maintained project with low issue volume, the maintainer addresses enhancement requests in a timely manner.

GitHub Issues serves as the publicly available archive for all bug reports, enhancement requests, and responses. All issues and comments are publicly searchable and permanently archived.
https://github.com/the-sarge/cpace/issues

The project maintains a vulnerability disclosure policy in SECURITY.md. Reports are directed to private channels (email or GitHub private vulnerability reporting). The project commits to acknowledging vulnerability reports within 7 calendar days, providing initial triage/status within 14 calendar days, coordinating disclosure timing with reporters, and providing periodic updates while confirmed issues are unresolved.
https://github.com/the-sarge/cpace/blob/main/SECURITY.md [osps_vm_01_01]

Private vulnerability reporting is available directly to the project’s security contact via email (the-sarge@the-sarge.com) and through GitHub’s private vulnerability reporting feature, as documented in SECURITY.md.
https://github.com/the-sarge/cpace/blob/main/SECURITY.md [osps_vm_03_01]

No vulnerability reports have been received in the last 6 months. As such, there are no response times to measure against the 14-day requirement. This criterion is marked N/A.

The project uses the standard Go toolchain (go build and go install) as its build system, which can automatically rebuild the software from source code. Additional validation and build automation is provided via Taskfile.yml.
https://github.com/the-sarge/cpace/blob/main/Taskfile.yml

The project uses the standard Go toolchain (go build and go install) as its build system, which can automatically rebuild the software from source code. Additional validation and build automation is provided via Taskfile.yml.
https://github.com/the-sarge/cpace/blob/main/Taskfile.yml

The project uses the standard Go toolchain (go build and go install) as its build system, which can automatically rebuild the software from source code. Additional validation and build automation is provided via Taskfile.yml.
https://github.com/the-sarge/cpace/blob/main/Taskfile.yml

The project’s GitHub Actions CI pipeline automatically runs the full test suite (go test ./..., vector tests, fuzz tests, and validation via Taskfile.yml) on every pull request before changes are merged to the primary branch.
https://github.com/the-sarge/cpace/blob/main/Taskfile.yml [osps_qa_06_01]

The project's test suite is invocable using the standard Go command go test ./..., which is the conventional and expected way to run tests for Go projects. Additional test and validation tasks are available via Taskfile.yml.

The project maintains a comprehensive test suite including unit tests (api_test.go, strings_test.go), example tests, protocol vector tests, and fuzz tests. The tests cover the main API, string handling, protocol vectors, and edge cases. All tests are run automatically via CI (go test ./...).

The project’s GitHub Actions CI pipeline automatically runs the full test suite (go test ./..., vector tests, fuzz tests, and validation via Taskfile.yml) on every pull request before changes are merged to the primary branch.
https://github.com/the-sarge/cpace/blob/main/Taskfile.yml [osps_qa_06_01]

The project follows a policy (enforced via CI and documented in CONTRIBUTING.md) that major new functionality must include corresponding tests in the automated test suite. All pull requests must pass the full test suite (go test ./...) before being merged.
https://github.com/the-sarge/cpace/blob/main/CONTRIBUTING.md

Recent changes to the project include corresponding test updates alongside new functionality (visible in the commit history and pull requests). All changes are required to pass the full automated test suite (go test ./...) before merging, providing clear evidence that the test policy is being followed.

CONTRIBUTING.md states that major behavior, API, parser/framing, security, protocol, CI/release, or dependency changes should add or update automated tests covering the changed functionality, or explain substitute evidence.
https://github.com/the-sarge/cpace/blob/main/CONTRIBUTING.md [osps_qa_06_03]

The project uses Go's built-in linter go vet and the security-focused linter gosec in its CI pipeline to detect code quality issues and common mistakes. Additional linters such as golangci-lint or staticcheck can also be used.
https://github.com/the-sarge/cpace/blob/main/docs/ci-policy.md

The project addresses warnings from go vet and gosec by fixing them or marking false positives in the source code. The CI pipeline is configured to fail on new warnings, ensuring they are promptly addressed.

The project is maximally strict with warnings where practical. The CI pipeline treats warnings from go vet and gosec as failures, ensuring all warnings are addressed before code is merged.

The primary developer (the-sarge) has demonstrated knowledge of secure software design principles through the project's extensive security documentation. This includes threat modeling (docs/threat-model.md), security assessment (docs/security-assessment.md), security specification audit, and adherence to principles such as least privilege, input validation with allowlists, limited attack surface, fail-safe defaults, and open design.
https://github.com/the-sarge/cpace/blob/main/docs/threat-model.md
https://github.com/the-sarge/cpace/blob/main/docs/security-assessment.md

The primary developer understands common vulnerability classes relevant to cryptographic software, including weak randomness, side-channel attacks, improper key handling, timing attacks, and insecure session management. Mitigation techniques used in the project include use of crypto/rand, constant-time implementations where applicable, strict input validation, and secure session lifecycle management, as documented in docs/threat-model.md and docs/security-assessment.md.
https://github.com/the-sarge/cpace/blob/main/docs/threat-model.md
https://github.com/the-sarge/cpace/blob/main/docs/security-assessment.md

The project implements the CPace key exchange protocol using Ristretto255 (a publicly reviewed elliptic curve group based on Curve25519) and SHA-512 (a standard, publicly reviewed hash function), as specified in draft-irtf-cfrg-cpace-21. These are well-established, publicly published, and expert-reviewed cryptographic primitives.
https://github.com/the-sarge/cpace/blob/main/README.md
https://datatracker.ietf.org/doc/draft-irtf-cfrg-cpace/

This criterion does not apply because the project's primary purpose is to implement a cryptographic protocol (CPace key exchange using Ristretto255 and SHA-512). It is not a general-purpose application or library that happens to use cryptography.

All cryptographic functionality in the project is implemented using FLOSS (Free/Libre Open Source Software). The project uses the Go standard library (crypto/rand, crypto/sha512) and open-source Ristretto255 implementations. No proprietary or closed-source cryptographic components are used.

The project uses Ristretto255 (255-bit elliptic curve keys), which significantly exceeds the NIST minimum requirements through 2030 (224 bits for elliptic curves). The implementation is fixed to Ristretto255 and does not support or allow smaller key lengths, satisfying the requirement to disable weaker options.

The project uses Ristretto255 (modern elliptic curve) and SHA-512 (secure hash function). It does not depend on any broken cryptographic algorithms (such as MD5, RC4, single DES, or Dual_EC_DRBG) or inappropriate cipher modes (such as ECB or unauthenticated CTR).

The project uses SHA-512 and Ristretto255, which do not have known serious weaknesses. It does not depend on SHA-1, CBC mode, or any other algorithms or modes with known serious weaknesses.

The CPace protocol implemented by the project provides perfect forward secrecy. Session keys derived from long-term secrets (passwords) cannot be compromised if those long-term secrets are later revealed, as specified in draft-irtf-cfrg-cpace-21.

This criterion does not apply. The project implements a password-authenticated key exchange (PAKE) protocol (CPace) and does not store passwords for authenticating external users in the traditional sense (inbound authentication with stored password hashes on a server).

The project uses Go's crypto/rand package to generate all cryptographic keys and nonces. This is Go's cryptographically secure random number generator and is explicitly documented in the project README.
https://github.com/the-sarge/cpace/blob/main/README.md

Distribution channels use HTTPS exclusively. [osps_br_03_02]

The project distributes all releases, source code, and any associated checksums exclusively over HTTPS via GitHub. No cryptographic hashes are retrieved over HTTP without signature verification.

There are no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days. As a draft-stage project with limited public exposure, no such vulnerabilities have been reported or identified to date.

The project commits to rapidly fixing all critical vulnerabilities after they are reported, as documented in SECURITY.md. No critical vulnerabilities have been reported to date.

The repository contains only source code, Go modules (go.mod/go.sum), documentation, and configuration files. No unencrypted secrets, credentials, API keys, or other sensitive data are present in the version control history. A .gitignore file is used to prevent accidental commits of sensitive files. The project runs govulncheck and gosec in CI to help detect potential issues.
https://github.com/the-sarge/cpace (root of repository)
https://github.com/the-sarge/cpace/blob/main/.gitignore [osps_br_07_01]

The project has a required SAST Gate status check that runs SAST tooling on pull requests before merge. It blocks codebase changes when security weaknesses are detected, except for documented false-positive or non-exploitable suppressions.
https://github.com/the-sarge/cpace/blob/main/.github/workflows/sast-gate.yml
https://github.com/the-sarge/cpace/blob/main/docs/security-gates.md [osps_vm_06_02]

The project uses gosec as one of its static analysis tools in CI. gosec includes rules specifically designed to detect common vulnerabilities in Go code, such as hardcoded credentials, weak cryptographic algorithms, SQL injection risks, and unsafe operations. The project also uses go vet, staticcheck, ast-grep, CodeQL, and Capslock.

The project defines SAST remediation thresholds for CodeQL, gosec, ast-grep, and manual security review findings, with documented false-positive or non-exploitable suppressions.
https://github.com/the-sarge/cpace/blob/main/docs/security-gates.md [osps_vm_06_01]

Static source code analysis is performed on every commit and pull request via the project's GitHub Actions CI pipeline.

The project applies dynamic analysis via fuzz testing (fuzz_test.go) as part of its validation process before releases. The OSS-Fuzz project is used as well. Fuzzing evidence and campaigns are documented in docs/fuzz-evidence.md.
https://github.com/the-sarge/cpace/blob/main/docs/fuzz-evidence.md

This criterion does not apply. The project is written entirely in Go, which is a memory-safe language with garbage collection and bounds checking. No memory-unsafe languages (such as C or C++) are used.

The project enables extensive assertions and checks during dynamic analysis (fuzz testing and CI validation). The Taskfile.yml validation targets (task check, task fuzz) and fuzz tests include strict checking and panic-on-failure modes to detect issues early during testing.
https://github.com/the-sarge/cpace/blob/main/Taskfile.yml

No medium or higher severity exploitable vulnerabilities have been discovered through dynamic code analysis (fuzz testing). As such, there are no vulnerabilities requiring fixes under this criterion, however the project is committed to fixing any possible future vulnerabilities discovered with dynamic code analysis in a very timely way.