tsoracle

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.

All development occurs in this public GitHub repository. Every commit between tagged releases is publicly visible on the main branch, and changes are landed via public pull requests that remain in the repository history. There is no private development fork; the public repo is the canonical source of truth.

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

Each published artifact has a unique SemVer identifier. The workspace publishes multiple crates to crates.io, and each crate is released under its own <crate-name>-v<MAJOR.MINOR.PATCH> git tag (e.g., tsoracle-v0.1.14, tsoracle-server-v0.2.9, tsoracle-driver-openraft-v0.3.3). The version in each crate's Cargo.toml matches its tag, so the version string a user sees via cargo or in a Cargo.lock uniquely identifies the released code state. Every release additionally has a unique git commit SHA on main.

URL: https://github.com/prisma-risk/tsoracle/releases

Release notes are published via the GitHub Releases workflow for every tagged version, and mirrored in per-crate CHANGELOG.md files under crates/*/CHANGELOG.md using the Keep a Changelog format with Added / Fixed / Other sections and PR links. They are generated by release-plz from Conventional Commits — i.e., curated human-readable summaries, not raw git log output. The repository is a Cargo workspace, so each published crate (binary, server, client, drivers, toolkits) has its own SemVer track and its own changelog entry per release.

No publicly known run-time vulnerability has ever been assigned a CVE or published as a GitHub Security Advisory against tsoracle. The repository's Security Advisories list (https://github.com/prisma-risk/tsoracle/security/advisories) is empty, and no CVE-* / GHSA-* identifier appears in any release's notes (https://github.com/prisma-risk/tsoracle/releases) or per-crate CHANGELOG.md. Per the criterion text, this case selects N/A. The project's SECURITY.md documents the private reporting channel so that when a vulnerability is reported and fixed, future release notes can identify it by CVE/GHSA.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/prisma-risk/tsoracle/blob/main/SECURITY.md. [osps_do_02_01]

GitHub Issues is the project's issue tracker (https://github.com/prisma-risk/tsoracle/issues). It is publicly readable, supports anyone with a GitHub account filing new issues, supports labeling, milestones, assignment, cross-references to commits/PRs, and search across open and closed history.

Bug reports and feature requests are tracked at https://github.com/prisma-risk/tsoracle/issues and responded to by the maintainer. Issues are triaged within days of being filed; the majority are resolved by a merged PR within weeks. The issue tracker is public, supports labeling, and links bidirectionally to commits and PRs.

Enhancement requests filed as GitHub Issues are responded to by the maintainer. Where an enhancement is accepted, a tracking issue or PR is opened; where rejected, the rationale is recorded on the issue thread. The issue tracker at https://github.com/prisma-risk/tsoracle/issues is the canonical channel.

URL: https://github.com/prisma-risk/tsoracle/issues?q=is%3Aissue

GitHub Issues serves as the public, permanent archive of bug reports, feature requests, and discussion. Closed issues remain visible and searchable; every issue has a stable URL. PRs are similarly archived at https://github.com/prisma-risk/tsoracle/pulls?q=is%3Apr.

URL: https://github.com/prisma-risk/tsoracle/blob/main/SECURITY.md

SECURITY.md documents the vulnerability reporting process end-to-end: where to file a report (private draft Security Advisory at https://github.com/prisma-risk/tsoracle/security/advisories/new — not public issues), what information to include (affected versions, impact assessment, minimal reproduction, severity estimate), the project's response commitments (24h acknowledgment, 72h triage, 30d coordinated disclosure or sooner on fix release), the in-scope and out-of-scope surface, and the post-fix public-disclosure flow with CVE request via the GitHub CNA.

URL: https://github.com/prisma-risk/tsoracle/security/advisories/new

The project's SECURITY.md directs reporters to GitHub's private Security Advisories channel, which is encrypted in transit (TLS) and visible only to repository maintainers. SECURITY.md additionally invites reporters to request an out-of-band encrypted channel via a follow-up comment on the advisory if they need stronger pre-disclosure secrecy.

No vulnerability reports have been received against tsoracle to date. The project's Security Advisories list (https://github.com/prisma-risk/tsoracle/security/advisories) contains zero advisories, draft or published. When a report is received, SECURITY.md commits the project to acknowledgment within 24 hours and triage within 72 hours; the criterion will become demonstrably Met after the first report is responded to within those windows.

Non-trivial build file in repository: https://github.com/prisma-risk/tsoracle/blob/main/Makefile.

Non-trivial build file in repository: https://github.com/prisma-risk/tsoracle/blob/main/Makefile.

The build uses cargo and the rustc Rust compiler — both released under the FLOSS dual MIT/Apache-2.0 license (https://github.com/rust-lang/rust/blob/master/COPYRIGHT). Supporting build-time tools enforced by CI (protoc, buf, clang/libclang, cargo-llvm-cov, cargo-deny) are all FLOSS. No proprietary tooling is required to build the project from source.

.github/workflows/ci.yml runs cargo test --workspace --all-features --locked on every push and PR, covering unit tests in each of the 17 workspace crates, integration tests under crates/*/tests/ (monotonicity, single_node, three_node, snapshot_transfer, restart_replay, linearized_barrier, reconfiguration, dynamic_membership, and ~20 more), plus the failpoints (docs/failpoint-testing.md) and yieldpoints (docs/yieldpoint-testing.md) feature suites. A cross-platform driver-file job runs on Ubuntu, macOS, and Windows. Out-of-process: 15+ libFuzzer harnesses (fuzz/fuzz_targets/), the kube-e2e and mixed-version-soak Kubernetes acceptance lanes (kube-e2e.yml, kube-e2e-mixed-version.yml), the stress-smoke PR job (mem/raft/paxos/process topologies with a positive-control inject-violation step), and nightly leak/fuzz/stress workflows.

URL: https://github.com/prisma-risk/tsoracle/blob/main/CONTRIBUTING.md

The project's tests are invoked with cargo test --workspace --all-features (documented under 'Running the checks locally' in CONTRIBUTING.md). The Makefile additionally provides convenience targets such as make test-failpoints and make coverage.

Coverage is measured by cargo-llvm-cov in the coverage CI job and uploaded to Coveralls (https://coveralls.io/github/prisma-risk/tsoracle). The most recent measurement is approximately 95% line coverage across the workspace, indicating that most major functionality is exercised by automated tests. Critical paths (consensus drivers, timestamp allocator, leader handoff) are covered by dedicated integration test files and additionally by fuzz harnesses for input-decoder paths.

URL: https://github.com/prisma-risk/tsoracle/blob/main/.github/workflows/ci.yml

CI runs on every push to main and every pull request via .github/workflows/ci.yml. Jobs: test (full workspace), cross-platform driver-file (ubuntu/macOS/Windows), buf (proto lint/format/breaking), deny, critical-path, header-check, fuzz-lockfile, coverage, stress-smoke. Additional workflows trigger on schedule or specific paths: fuzz-pr.yml (per-PR), fuzz-nightly.yml, kube-e2e.yml, kube-e2e-mixed-version.yml, leak-nightly.yml, stress-nightly.yml, scorecard.yml, release-plz.yml, release-images.yml, pages-build-check.yml, pages.yml.

URL: https://github.com/prisma-risk/tsoracle/blob/main/CONTRIBUTING.md#test-policy
CONTRIBUTING.md has an explicit ## Test policy section requiring that every contribution adding new functionality MUST include automated tests exercising it, and every bug fix MUST include at least one regression test that fails on the unfixed code and passes on the fix. Tests run via cargo test --workspace --all-features as a CI required check. Exempt: docs:, refactor:, chore: Conventional Commits prefixes (no runtime behavior change). Enforced at review time, backed by measured workspace line coverage (cargo-llvm-cov → Coveralls, currently ~95%).

Recent commit history on the main branch (https://github.com/prisma-risk/tsoracle/commits/main) shows that non-trivial code changes are typically accompanied by tests. Examples from recent months: barrier-seq durable seed (M5), snapshot publish TOCTOU (M4), WatchGuard drop sync stepdown (M3), shutdown stall on hung driver (M2), paxos lease generation wrap, openraft peer RPC deadline — each shipped with the regression test that proved the fix. The CI required-checks gate prevents fixes from landing without tests at the architectural level the change touched.

The project enables compiler warnings via cargo's default warning set, and Clippy lints — the canonical Rust linter — are run in CI with cargo clippy --workspace --all-targets --all-features --locked -- -D warnings (see .github/workflows/ci.yml). The -D warnings flag promotes every warning to a hard error, so any warning in any workspace crate fails CI. Library and binary crates additionally carry #![cfg_attr(not(test), warn(clippy::unwrap_used, clippy::expect_used))] at the crate root to flag panicking calls in non-test code (documented in CONTRIBUTING.md).

Because clippy runs with -D warnings in CI as a required check, no PR can merge into main with an outstanding warning. The workspace contains no #![allow] overrides at the workspace or crate level for lint groups. The pre-commit hook in .husky/pre-commit additionally runs fmt + clippy locally before commit, surfacing warnings before they reach CI.

The project's CI runs cargo clippy --workspace --all-targets --all-features --locked -- -D warnings, treating every warning as a hard error. Library and binary crates additionally carry #![cfg_attr(not(test), warn(clippy::unwrap_used, clippy::expect_used))] to escalate panicking patterns in non-test code. No #![allow] overrides are present at the workspace level, and no workarounds (e.g., clippy.toml allow-unwrap-in-tests) are used to silence the lint.

At least one project member is familiar with secure design principles, demonstrated by concrete decisions: (1) TLS/mTLS on peer and admin transport, with a secure-by-default Helm chart guard that refuses to render an HA openraft/paxos deployment without TLS unless tls.allowInsecurePeer=true is set explicitly; (2) fail-closed defaults across the consensus/timestamp critical path (single-active leadership-stream lease, synchronous WatchGuard step-down at the drop site, openraft graceful handoff transferring leadership before drain); (3) defense-in-depth on the client (per-pass + absolute redirect caps, MAX_TOTAL_LEADER_REDIRECTS=64); (4) SECURITY.md with the report→triage→CNA-coordinated CVE disclosure flow; (5) input validation at the gRPC decode boundary backed by 15+ libFuzzer harnesses.

At least one project member is familiar with common errors leading to vulnerabilities. The implementation language is safe Rust, which structurally excludes the memory-safety class (buffer overflow, use-after-free, double-free, data races on Send/Sync types). For classes Rust does not prevent: (1) 15+ libFuzzer harnesses (fuzz/fuzz_targets/) exercise codec/proto decode paths against malformed input, run per-PR and nightly with auto-issue filing on crash; (2) cargo-deny enforces a FLOSS-only license allow-list and the RustSec advisory database in the deny CI job; (3) OpenSSF Scorecard runs on every push and weekly cron; (4) Dependabot updates GitHub Actions, the fuzz workspace, and base image digests; (5) base images pinned by SHA256 in deploy/Dockerfile.

The project does not implement cryptographic algorithms itself. Where it uses cryptography (TLS for the gRPC client/server and peer transport), it relies on rustls via tonic, which uses the published ring / aws-lc-rs providers exercising standardized algorithms documented by IETF RFCs (TLS 1.3 cipher suites, ECDSA, RSA-PKCS#1, X25519, AES-GCM, ChaCha20-Poly1305).

The project does not implement cryptography itself and does not expose cryptographic algorithm selection to its users as a tunable surface. Cryptographic choices are delegated to rustls/tonic defaults (modern TLS 1.3 cipher suites). The criterion applies to projects that select among multiple cryptographic algorithms at the application layer; tsoracle does not.

All cryptographic implementations the project depends on are FLOSS: rustls (Apache-2.0/MIT/ISC), ring (ISC with a mixed-license historical statement), tonic (MIT). The cargo-deny deny.toml license allow-list (Apache-2.0, MIT, BSD-3-Clause, ISC, Unicode-3.0, Zlib) is enforced in CI and would reject a non-FLOSS crypto dependency on the next PR.

The project uses TLS 1.3 via rustls defaults, which selects key lengths providing at least 128-bit security (X25519 with curve25519 / P-256 / RSA-2048 minimum / AES-128-GCM / AES-256-GCM / ChaCha20-Poly1305). The project does not implement its own crypto with sub-112-bit-security algorithms.

The project uses TLS 1.3 via rustls defaults. The rustls default profile rejects TLS 1.0/1.1 and weak/broken cipher suites (MD5 signature algorithms, RC4, DES/3DES, NULL ciphers, export-grade key exchange). The project does not use known-broken algorithms anywhere in its own source.

The project does not implement cryptographic algorithms; it consumes rustls via tonic. Rustls maintains its own cipher-suite hygiene upstream — no SHA-1 in signature contexts, no RC4, no DES/3DES, no 64-bit block ciphers, no TLS 1.0/1.1, no insecure curves — and tsoracle inherits those choices via the rustls default ClientConfig/ServerConfig.

TLS 1.3 — the only protocol version rustls offers by default for tsoracle's transports — mandates ephemeral Diffie-Hellman key exchange (X25519 / secp256r1 / secp384r1) for every handshake, so perfect forward secrecy is provided for every session.

The project does not authenticate users by password. Authentication between peers and between clients and the server is via mutual TLS (X.509 certificates), not passwords. No user-supplied secret is stored or compared by the project.

The project uses the rand crate (workspace pin: rand = { version = '0.9', default-features = false, features = ['std', 'std_rng'] }) where std_rng is ChaCha12Rng, a cryptographically-secure PRNG, seeded via the getrandom crate from the OS CSPRNG (/dev/urandom, getrandom(2), BCryptGenRandom per platform). For TLS, rustls uses its provider's CSPRNG (ring/aws-lc-rs). The project does not use thread_rng() in security-critical paths and does not implement its own PRNG.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Distributed artifacts include cryptographic integrity protection: (1) crates.io tarballs are referenced by SHA-256 in any consumer's Cargo.lock, so a transport-level tamper would change the consumer's lockfile; (2) container images on ghcr.io are content-addressable by SHA256 digest, and the project's deploy/Dockerfile pins base images by digest (FROM rust:1-bookworm@sha256:6258907abe... and FROM debian:bookworm-slim@sha256:0104b334...); (3) GitHub release tags are immutable git references identified by SHA-1 commit; (4) distribution channels themselves are HTTPS-only (see delivery_mitm).

No publicly known vulnerability has been disclosed against tsoracle to date — the project's Security Advisories list (https://github.com/prisma-risk/tsoracle/security/advisories) contains zero advisories, draft or published, and no CVE has been assigned. Therefore there has been no past instance where the 60-day clock could be either met or missed. The project's SECURITY.md commits to coordinated disclosure within 30 days from report (or sooner on fix release), well inside the 60-day criterion.

No critical vulnerability has been publicly disclosed against tsoracle. SECURITY.md commits the project to coordinated disclosure within 30 days and to requesting a CVE via the GitHub CNA when the impact warrants one.

A grep of the repository for common secret patterns (BEGIN PRIVATE KEY, BEGIN RSA PRIVATE KEY, BEGIN OPENSSH PRIVATE KEY, AKIA[0-9A-Z]{16}, ghp_, aws_access_key) across .rs, .toml, .yml, and .md files returns zero matches. The only TLS/PKI material in the repository is test-only certificate generation via the rcgen crate at test-fixture time; no static private keys are committed. .gitignore excludes typical credential paths, and OpenSSF Scorecard's pinned-dependencies / token-permissions checks run on every push.

Three static-analysis categories run on every push and PR (.github/workflows/ci.yml): (1) Clippy with cargo clippy --workspace --all-targets --all-features --locked -- -D warnings denying every warning; (2) cargo-deny with cargo deny check enforces the FLOSS-only license allow-list (deny.toml) and the RustSec advisory database against the resolved dependency tree; (3) OpenSSF Scorecard supply-chain analysis (.github/workflows/scorecard.yml). Two project-specific guards also run: scripts/check-critical-path.sh (no tracing!/println!/sync-I/O on hot-path files) and scripts/check-ts-header.py (canonical Apache-2.0 short license header).

OpenSSF Scorecard (.github/workflows/scorecard.yml) flags supply-chain and project-management common-vulnerability classes (token permissions, branch protection, pinned dependencies, dangerous workflow patterns). cargo-deny (.github/workflows/ci.yml deny job) checks the RustSec advisory database for known CVEs in the dependency graph on every PR. Clippy's default lint set includes lints for common error classes that Rust does not prevent at compile time (uninit reads, panicking calls in non-test code via the unwrap_used/expect_used escalation).

Because clippy runs with -D warnings (denying every warning to error) and the deny / header-check / critical-path guards are all required CI gates, no PR can merge with an outstanding static-analysis finding. The workspace contains no global #![allow] overrides on lint groups.

Static analysis runs on every push to main and every pull request (see the clippy, deny, header-check, and critical-path jobs in .github/workflows/ci.yml — triggered by on: push: branches: [main] and on: pull_request). OpenSSF Scorecard runs additionally on a weekly cron (43 18 * * 6 in .github/workflows/scorecard.yml) and on every main-branch push.

The project runs multiple dynamic-analysis modes: (1) libFuzzer harnesses in fuzz/fuzz_targets/ (15+ targets) running per-PR (.github/workflows/fuzz-pr.yml) and nightly (.github/workflows/fuzz-nightly.yml) with auto-issue filing on crash; (2) Kubernetes e2e in real cluster lanes (kube-e2e.yml, mixed-version-soak); (3) stress lanes with monotonicity assertion and positive-control inject-violation step (stress-smoke and stress-nightly.yml); (4) leak-nightly (.github/workflows/leak-nightly.yml) for memory leaks; (5) failpoint and yieldpoint test scaffolding for software-fault injection during integration runs.

Where the project uses dynamic analysis (libFuzzer in fuzz/, kube-e2e + mixed-version-soak in e2e/kube/, stress-smoke + stress-nightly, leak-nightly), it exercises the program against malformed or adversarial input and under real-world fault injection. The failpoints and yieldpoints test scaffolding (see docs/failpoint-testing.md and docs/yieldpoint-testing.md) injects software faults during integration runs, and the stress lane's positive-control inject-violation step proves the monotonicity-violation detector still fires. Findings are addressed before merge.

Rust's debug_assert! macros are active in debug builds (default for cargo test) and in stress-smoke, kube-e2e, and fuzz harness binaries (libFuzzer builds in debug). The project uses debug_assert! liberally on invariant-protection paths (e.g., the openraft LeaderState contract guard at run_leader_watch, the PaxosRunner start guard, the consensus barrier-seq invariants).

All medium-or-higher dynamic-analysis findings are fixed and gated on main: (1) libFuzzer harnesses in fuzz/fuzz_targets/ run per-PR (fuzz-pr.yml) and nightly with a 30-minute/target budget (fuzz-nightly.yml), crashes auto-file as issues with the offending input; (2) kube-e2e and mixed-version-soak (kube-e2e.yml, kube-e2e-mixed-version.yml) gate on a 0.05% soak error budget; (3) stress-smoke runs mem/raft/paxos/process topologies with a positive-control inject-violation step that must exit 1 to prove the supervisor still catches monotonicity breaks; (4) leak-nightly (leak-nightly.yml) runs nightly. None report unresolved findings on main.