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.