c2pa-vtt

Repository is public: gh repo view writerslogic/c2pa-vtt reports isPrivate=false, visibility=PUBLIC, at https://github.com/writerslogic/c2pa-vtt.

Git (.git/) records author, committer, timestamp, and message for every change; git log --format='%an <%ae>' and git log --oneline confirm full change/author/time tracking.

40 commits exist between the first commit (2026-05-14) and the only release tag v0.2.0 (2026-08-02) and after it, not just release-boundary commits; e.g. 464cee0, a37106b, 39624cd, f52e3be are all interim commits after the v0.2.0 tag.

Repository uses git, a distributed version control system.

Cargo.toml declares version = "0.2.0", a unique identifier for the release; git tag v0.2.0 matches it exactly (release.yml verifies tag-vs-Cargo.toml version equality before publishing).

Version 0.2.0 in Cargo.toml follows Semantic Versioning (MAJOR.MINOR.PATCH).

git tag -l returns v0.2.0, matching the GitHub release at https://github.com/writerslogic/c2pa-vtt/releases/tag/v0.2.0.

No publicly known vulnerabilities have been fixed in any release to date (no GitHub Security Advisories exist for this repo), so there is nothing that would need to be identified in release notes.

GitHub Issues is used as the tracker for individual issues, e.g. issue #1 'Add doc-tests for embed, extract, and remove' and #2 'Handle malformed VTT input gracefully' (both closed, confirmed via gh api repos/writerslogic/c2pa-vtt/issues?state=all).

GitHub Issues at https://github.com/writerslogic/c2pa-vtt/issues is a public, searchable archive of all reports and responses.

SECURITY.md explains two private channels: a GitHub Security Advisory (https://github.com/writerslogic/c2pa-vtt/security/advisories/new) or email to admin@writerslogic.com.

No vulnerability reports have been received (no GitHub Security Advisories exist for this repo as of 2026-08-26), so there is no response-time history to evaluate.

Rust crate built with cargo check/build (.github/workflows/ci.yml "cargo check --all-features" job).

Cargo, the standard Rust build tool, is used (Cargo.toml, Cargo.lock); CONTRIBUTING.md documents cargo build and cargo test.

Cargo and rustc (used in CI via dtolnay/rust-toolchain in .github/workflows/ci.yml) are FLOSS; wasm-pack and maturin (release.yml) used for the npm/PyPI builds are also FLOSS.

tests/e2e.rs and tests/bridge_c2pa.rs plus inline unit tests in src/*.rs form a FLOSS (Rust, MIT/Apache-2.0) automated test suite; running it is documented in CONTRIBUTING.md ('cargo test --all-features') and .github/workflows/ci.yml.

Tests run with the standard Rust invocation cargo test --all-features, documented in .github/workflows/ci.yml and release.yml.

tests/e2e.rs (106 lines) and tests/bridge_c2pa.rs (107 lines) plus inline unit tests in src/embed.rs (9), src/extract.rs (12), src/binding.rs (5), src/bridge.rs (3), src/error.rs (3) cover embed/extract/hard-binding/validation-bridge logic across the default and c2pa feature flags. Gap disclosed: src/python.rs and src/wasm.rs (the PyO3/wasm-bindgen FFI wrapper layers, each grep -c '#\[test\]' = 0) have no dedicated tests of their own; only the underlying Rust functions they wrap are tested.

.github/workflows/ci.yml 'test' job runs cargo test --all-features on every push to main and every pull request.

CONTRIBUTING.md 'Submitting Changes' step 2 states: 'Make changes, add tests, run cargo test --all-features.'

Commit d095583 'feat: v0.2.0 -- modular embed/extract/hard-binding + c2pa-rs validation bridge, e2e tests' added tests/bridge_c2pa.rs and tests/e2e.rs alongside the new functionality; commit 893096a 'fix(test): follow the c2pa-rs 0.89.3 ValidationResults API change' updated tests/bridge_c2pa.rs when the dependency's API changed.

CONTRIBUTING.md 'Submitting Changes' explicitly instructs contributors to add tests as part of the PR process.

.github/workflows/ci.yml 'check' job runs cargo clippy --all-features -- -D warnings and cargo fmt --all -- --check on every push/PR; release.yml 'verify' job additionally runs clippy across --all-targets, --target wasm32-unknown-unknown, and --features python.

-D warnings in both ci.yml and release.yml turns any clippy warning into a build failure, so merges to main and releases cannot land with unfixed warnings.

Evidence of secure-design awareness: SECURITY.md 'Supply-chain security' section (pinned Action SHAs, Scorecard, Dependabot, build provenance); src/lib.rs:52 #![forbid(unsafe_code)]; README.md 'Hard binding' section documents the byte-exact exclusion-range tamper model and explicitly discusses failure modes (re-encoding fragility, why no Unicode normalization is applied to avoid false-negative tamper detection).

Security-focused commit history: a37106b 'fix(security): bump pyo3 to 0.29', 464cee0 'ci(security): pin actions by SHA and drop GITHUB_TOKEN to read', 18493fb 'fix(security): autofix 3rd party Github Actions should be pinned' (addressing supply-chain injection risk); src/lib.rs:52 #![forbid(unsafe_code)] forecloses an entire class of memory-safety errors.

Default hash feature uses SHA-256 via the sha2 crate (Cargo.toml); optional c2pa feature delegates COSE signature validation to the c2pa crate (spec.c2pa.org). Both are publicly published, standard algorithms/protocols.

Cargo.toml dependencies show sha2 (dedicated hashing crate) and optional c2pa (dedicated C2PA/COSE crate) are called rather than any crypto being reimplemented in this crate's own source.

sha2 and c2pa are both FLOSS crates published on crates.io.

This crate generates or selects no cryptographic keys itself; it computes a SHA-256 digest (not a key) for data-hash integrity, and delegates signing-key handling entirely to c2pa-rs via the optional c2pa feature (src/bridge.rs).

Default hash algorithm is SHA-256 (src/binding.rs, HashAlg via sha2), not MD4/MD5/single-DES/RC4/Dual_EC_DRBG.

Default is SHA-256, avoiding SHA-1 and other algorithms with known serious weaknesses.

This crate performs no network key-agreement protocol; it is an offline file-format embedding/hashing library.

This crate has no concept of user accounts or password storage; it is a WebVTT manifest-embedding library.

No key or nonce generation occurs in this crate's source: grep -rn 'rand|getrandom|OsRng' src/ Cargo.toml returns no matches. Any signing-key/nonce generation is c2pa-rs's responsibility, outside this crate.

Packages are delivered via crates.io, npmjs.com, and pypi.org, all HTTPS-only registries; release.yml publishes over HTTPS (cargo publish, npm publish, pypa/gh-action-pypi-publish).

No hash-only integrity check is retrieved over plain HTTP anywhere in the release process; all distribution channels (crates.io, npm, PyPI, GitHub Releases) are HTTPS.

One Dependabot alert on record (#2, GHSA-chgr-c6px-7xpp, pyo3 missing Sync bound) is state=fixed; no medium+ vuln has remained open >60 days (gh api repos/writerslogic/c2pa-vtt/dependabot/alerts).

Same alert (#2) was resolved promptly via dependency bump; no critical vulnerability found unaddressed.

tests/fixtures/certs/es256.pem and es256.pub contain an ES256 keypair, but it is a test-only fixture used to sign test C2PA manifests in tests/bridge_c2pa.rs (added in commit d095583 alongside the other test fixtures), not a credential for any real service, account, or production system -- standard practice for C2PA test suites. No other credential-shaped strings (API keys, tokens, passwords) were found in a repo-wide search excluding CI secret references (CARGO_REGISTRY_TOKEN, GITHUB_TOKEN, NPM_TOKEN, which are GitHub Actions secret placeholders, not literal values).

.github/workflows/ci.yml runs cargo clippy --all-features -- -D warnings on every push/PR, and .github/workflows/release.yml 'verify' job runs clippy (--all-targets, --target wasm32-unknown-unknown, --features python) as a gate before every publish -- i.e. static analysis is applied before every release.

-D warnings makes clippy findings build-breaking in both ci.yml and release.yml, so they are fixed before merge/release by construction.

ci.yml 'check' job (which runs clippy) triggers on every push to main and every pull request, not just periodically.

A cargo-fuzz target (fuzz/fuzz_targets/parse_untrusted.rs) drives the crate's untrusted-input parsers with libFuzzer; fuzz/README.md documents how to run it.

src/lib.rs:52 declares #![forbid(unsafe_code)], so no memory-unsafe (unsafe) Rust code exists in this crate to require dynamic memory-safety tooling.

The fuzz target builds with cargo-fuzz's default dev profile, which enables debug assertions and overflow checks, so Rust's integer-overflow and bounds checks act as assertions during fuzzing.

No dynamic analysis is performed (see dynamic_analysis), so there are no dynamic-analysis findings to fix.