Thornwood is security-critical cryptographic software. Reports of vulnerabilities are handled as a priority.

Thornwood is pre-1.0 and has not yet received a professional third-party audit. It has also not been formally verified end to end.

Pine uses Thornwood internally in scoped deployments behind a swappable provider seam. External adopters should treat it as pre-production until the independent audit, broader binary constant-time validation, and release-hardening gates are complete.

Release tags are annotated and SSH-signed. Verify them with release-signers.allowed_signers.

Email security@pinedawn.com with:

• A summary of the issue and the impact you observed.
• Steps to reproduce, ideally with a minimal proof of concept, payload, or test vector.
• The affected crate, API, target, commit, or version if known.
• Any disclosure timeline or coordination constraints.

Do not open a public GitHub issue for vulnerabilities.

A PGP key for security@pinedawn.com and an RFC 9116 /.well-known/security.txt will be published once provisioned. Until then, reports are received over plaintext email. If the report includes sensitive exploit details, keep the first message minimal and ask us to coordinate an encrypted channel.

Thornwood is maintained by Pine.

• Acknowledgement: best effort within 72 hours.
• Substantive response: best effort within 7 days.
• Critical issues are prioritized ahead of feature work.

Please coordinate public disclosure with Pine before publishing details.

The main security properties Thornwood is designed to preserve are:

• C-free cryptographic build graph for Thornwood's own provider and primitives.
• Isolated unsafe boundary in pine-thornwood-s2n.
• Fail-closed parsing, key generation, encapsulation, decapsulation, signing, and provider setup paths.
• Constant-time discipline for secret-bearing operations.
• Official vectors and differential tests for cryptographic behavior.
• Fuzzing for untrusted-input surfaces.
• Explicit auditability over cleverness.

The threat model is documented separately in THREAT_MODEL.md. The current assurance status is tracked in ASSURANCE.md.

Constant-time behavior is a property of compiled code on a target, not a promise that follows automatically from source style.

Thornwood uses source-level constant-time discipline, native binary-level checks, and targeted tests to reduce timing risk. WebAssembly is treated separately: engine lowering and JIT behavior are outside Thornwood's control, so the project does not make an unqualified binary-level constant-time claim for wasm.

unsafe is forbidden across the workspace except in pine-thornwood-s2n. That crate embeds pinned s2n-bignum assembly and wraps it with a narrow Rust API.

The vendored assembly is source code with preserved attribution and regeneration notes, not an opaque binary dependency. See crates/pine-thornwood-s2n/VENDOR.md.

openssl, native-tls, ring, and aws-lc-rs are not part of Thornwood's compiled cryptographic build graph. The repository uses CI, cargo deny, and dependency review hygiene to keep that boundary visible.

Cargo.lock can record inactive optional dependencies from selected upstream packages. The enforced boundary is Cargo's active normal dependency graph, which CI checks with tools/check-dependency-boundary.sh.

If a future change needs to relax this policy, it must be explicit, documented, and reviewed as a security decision.