c2pa-html

Public GitHub repository at https://github.com/writerslogic/c2pa-html (gh api confirms isPrivate=false); full git history readable without authentication.

git (via GitHub) records every commit's author, timestamp, and diff; e.g. 'git log' shows author David Condrey davidcondrey@me.com and dependabot[bot] with full commit messages and dates.

git log shows commits between the v0.1.0 and v0.2.0 tags (e.g. 89d01ad 'feat: add WebAssembly bindings and an npm release job', 472d7c0, 07efb37), not only tagged release commits.

Repository uses git, a distributed version control system, hosted on GitHub.

Cargo.toml version = "0.2.0"; git tags v0.1.0 and v0.2.0 each map to a unique commit and are published as unique crates.io/npm/PyPI package versions.

Versions 0.1.0 and 0.2.0 (git tag output) follow Semantic Versioning MAJOR.MINOR.PATCH format, matching Cargo.toml's version field.

git tag lists v0.1.0 and v0.2.0; both correspond to published GitHub Releases (gh release list shows v0.1.0 2026-07-31, v0.2.0 2026-08-02).

N/A because release_notes itself is Unmet (no curated release notes exist yet to identify fixed vulnerabilities in). No publicly disclosed CVE/vulnerability has been fixed in this project's history to date.

GitHub Issues (per-issue tracker) is used, with dedicated bug_report.yml and feature_request.yml templates under .github/ISSUE_TEMPLATE/.

GitHub Issues at https://github.com/writerslogic/c2pa-html/issues is a publicly readable, searchable, permanent archive of any reports and responses (currently empty, but the mechanism exists and is public per gh api has_issues=true).

N/A: no vulnerability reports have been received in the last 6 months (repo is ~4 weeks old, gh issue list shows zero issues, and no security advisories exist for this repo).

Standard Cargo build: cargo build (Cargo.toml, README.md line 23-25 shows dependency usage; CONTRIBUTING.md line 23 documents cargo build). CI (.github/workflows/ci.yml) runs cargo check, cargo build --target wasm32-unknown-unknown.

Uses Cargo, the standard Rust build tool, plus maturin/PyO3 for the Python wheel and wasm-bindgen/wasm-pack for the npm package (README.md lines 28-33, Cargo.toml [package.metadata.docs.rs] and pyo3 dependency) -- all standard, common tools for their respective language ecosystems.

Cargo, rustc, maturin/PyO3, and wasm-bindgen are all FLOSS. Cargo.toml shows zero non-optional dependencies ('Zero dependencies, no features', README.md line 166-170).

103 #[test] functions across src/base64.rs, src/document.rs, src/error.rs, src/hardbinding.rs, src/scan.rs, src/sha2.rs, and tests/roundtrip.rs (grep -c '#[test]' counts: 7+31+7+23+17+10+8). Run via cargo test, documented in CONTRIBUTING.md lines 20-25. All FLOSS (MIT/Apache-2.0, same as the crate).

cargo test is the standard Rust test invocation (CONTRIBUTING.md line 24, ci.yml 'test' job runs cargo test); documented in CONTRIBUTING.md Development Setup.

Core logic (discovery/scan, document embed/extract/remove, base64, hard-binding hash/verify, SHA-2 against NIST FIPS 180-4 vectors, error paths) is heavily tested: 103 test functions in src/*.rs and tests/roundtrip.rs. Gap: src/wasm.rs and src/python.rs (FFI binding layers) have zero #[test] functions (grep -c '#[test]' src/wasm.rs src/python.rs returns 0/0) -- only the core Rust API is directly unit-tested, not the WASM/Python surface.

.github/workflows/ci.yml 'test' job runs cargo test on every push to main and every pull request (paths-ignore markdown-only changes).

CONTRIBUTING.md line 30: 'Make changes, add tests, run cargo test --all-features' is an explicit stated policy that new changes include tests.

CONTRIBUTING.md 'Submitting Changes' step 2 explicitly documents the add-tests policy: 'Make changes, add tests, run cargo test --all-features' (line 30).

src/lib.rs lines 95-96 set #![warn(missing_docs)] and #![warn(missing_debug_implementations)] crate-wide; CI runs cargo clippy --all-targets -- -D warnings and cargo clippy --features python -- -D warnings (.github/workflows/ci.yml lines 39-40), and cargo fmt --all -- --check.

CI treats clippy warnings as build failures via -D warnings (ci.yml lines 39-40), so no clippy warning can persist on main without breaking CI. Commit 4b85f74 'chore: harden lints, docs, and CI' shows active warning cleanup.

src/lib.rs:94 #![forbid(unsafe_code)] is the strictest possible unsafe-code lint (hard compile error, stronger than deny/warn); combined with clippy -D warnings across all targets and the python feature, and rustfmt --check, this is a maximally strict practical warning configuration for this crate.

README.md explicitly documents secure-design reasoning for the crate's core function: hard-binding coverage semantics and why re-serialization invalidates a binding (lines 106-119), and a documented rationale for why SHA-2 is hand-rolled versus other crypto being out of scope (lines 172-180, 'A hash is the one primitive where writing it yourself is uncontroversial'). src/lib.rs:94 #![forbid(unsafe_code)] and SECURITY.md's supply-chain section (pinned SHA actions, least-privilege GITHUB_TOKEN in 8827fcf) show deliberate secure-design practice by the primary developer.

SECURITY.md 'Supply-chain security' section documents specific mitigations for common attack classes (actions pinned to SHAs against tag-mutation attacks, Scorecard/Dependabot, minimal GITHUB_TOKEN permissions -- commit 8827fcf 'ci(security): pin actions by SHA and drop GITHUB_TOKEN to read'). Commit 8249f36 'fix(security): bump pyo3 to 0.29' shows responding to a known dependency vulnerability class.

src/sha2.rs implements SHA-256/384/512 per the published FIPS 180-4 standard, tested against published NIST test vectors (README.md lines 172-175: 'implemented against FIPS 180-4 and tested against the NIST vectors').

The in-crate SHA-2 implementation (src/sha2.rs) is itself FLOSS (MIT OR Apache-2.0, same as the whole crate), and callers may substitute any FLOSS implementation via the Hasher trait (README.md lines 178-180).

N/A: the crate has no cryptographic keys of its own (hashing only, no signing/encryption/key-agreement); README.md lines 44-45 states 'Signature verification, certificate trust, assertion validation ... are not reimplemented here.'

src/hardbinding.rs exposes only SHA-256/384/512 (Algorithm::Sha256/384/512 per README.md line 96-101); no MD4, MD5, single-DES, RC4, or Dual_EC_DRBG anywhere in the codebase (grep of src/ shows only the sha2 module).

Only SHA-256/384/512 are offered as hard-binding digest algorithms (src/hardbinding.rs, src/sha2.rs); no SHA-1 or other weakened algorithm is used by default.

N/A: the crate performs no key agreement or network key exchange; it is a local hashing/embedding library (README.md lines 39-45).

N/A: the crate has no concept of user accounts or stored passwords; it is an HTML document manipulation library.

N/A: the crate generates no cryptographic keys or nonces and has zero dependencies including no RNG crate (Cargo.toml shows no rand/getrandom dependency); hashing is deterministic over caller-supplied bytes.

Package is delivered via crates.io, npmjs.com, and PyPI (README.md lines 22-33), all served exclusively over HTTPS; source is fetched via git clone https://github.com/writerslogic/c2pa-html.git (CONTRIBUTING.md line 21, also HTTPS).

No hash-only integrity check is distributed over plain HTTP; all distribution channels (crates.io, npm, PyPI, GitHub over HTTPS) use TLS-protected transport, and README.md line 24 notes releases include build provenance where the registry supports it.

No publicly disclosed medium-or-higher vulnerability is currently open against this project (gh api shows no security advisories; gh issue list returns zero issues). Commit 8249f36 'fix(security): bump pyo3 to 0.29' (2026-08-04, same day as v0.2.0's predecessor commits) shows a dependency security fix applied promptly, well within 60 days.

No critical vulnerability has been publicly reported against this project to date (repo is ~4 weeks old with zero issues/advisories filed per gh issue list and gh api), so no case of slow response exists; the one dependency security fix observed (8249f36, pyo3 bump) landed the same day as related hardening work (4b85f74, 8827fcf), showing responsiveness.

git log --all -p searched for api key/secret/password/private-key/token patterns found only legitimate GitHub Actions secret references (${{ secrets.CARGO_REGISTRY_TOKEN }}, ${{ secrets.NPM_TOKEN }}, ${{ github.token }} in .github/workflows/release.yml) and unrelated source matches (HTML 'token list' parsing in src/scan.rs, doc comments about there being 'no secret to leak' in a hash). No embedded credential, API key, or private key material found.

clippy (a FLOSS static analysis tool for Rust) is run in CI on every push/PR: cargo clippy --all-targets -- -D warnings and cargo clippy --features python -- -D warnings (.github/workflows/ci.yml lines 39-40, also in release.yml lines 52-54).

CI enforces -D warnings on clippy (ci.yml lines 39-40), so any clippy finding fails the build and must be fixed before merge; commit 4b85f74 'chore: harden lints, docs, and CI' shows active lint remediation.

clippy runs in CI on every push to main and every pull request (.github/workflows/ci.yml triggers, lines 6-12), i.e. on every commit, not just before releases.

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.

N/A: src/lib.rs line 94 #![forbid(unsafe_code)] makes any unsafe block a hard compile error; grep -rn 'unsafe' src/ confirms the only occurrence is that forbid attribute itself -- there is no memory-unsafe code to analyze.

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.

N/A: no dynamic analysis tool is run (see dynamic_analysis, Unmet), so no medium+ dynamic-analysis findings exist to have been fixed.