# Trust Dashboard

This dashboard is a concise adoption checklist for security-sensitive users.
It describes the current release posture and should be refreshed before each
stable release.

| Area | Current Status | Evidence |
| --- | --- | --- |
| License | `MIT OR Apache-2.0` | `Cargo.toml`, `LICENSE-MIT`, `LICENSE-APACHE` |
| MSRV | Rust `1.90.0` | `Cargo.toml`, CI compatibility matrix |
| Active release toolchain | Rust `1.96.1`; MSRV remains Rust `1.90.0` | `rust-toolchain.toml`, `scripts/ci_install_rust.sh` |
| Runtime dependencies | Zero external crates in the core package; optional companion crates are separate opt-in packages | `scripts/validate-dependencies.sh`, `scripts/check_companion_crates.sh` |
| Default dev dependencies | Zero external crates | `Cargo.toml` |
| Optional runtime features | `alloc`, `std`, `stream`; `allow-wasm32-best-effort-wipe` explicit wasm cleanup-limit acceptance; `allow-compiler-fence-only-wipe` explicit unsupported-native cleanup-limit acceptance; reserved `simd`, `tokio`, `kani`, `fuzzing`. AArch64 CSDB attestation uses custom cfg `base64_ng_aarch64_csdb_attested`, not a feature. | `Cargo.toml`, `scripts/check_reserved_features.sh`, `scripts/check_wasm_wipe_policy.sh` |
| Unsafe policy | Scalar encode/decode remains safe Rust; audited unsafe is limited to volatile wiping, constant-time comparison, CT alphabet scan and result-gate barriers, and the reviewed SIMD boundary; runtime unsafe-boundary reports are conservative and mark SIMD-enabled builds as not high-assurance-boundary-enforced | `src/cleanup.rs`, `src/ct/`, `src/simd/`, `docs/UNSAFE.md` |
| Active backend | Scalar by default; std x86/x86_64 AVX-512 VBMI encode preferred, then AVX2, then SSSE3/SSE4.1 encode, plus little-endian std aarch64 NEON encode, when `simd` is enabled and platform checks pass. Strict decode has a separate runtime report method and may use std x86/x86_64 AVX-512 VBMI, AVX2, SSSE3/SSE4.1, or little-endian std aarch64 NEON. wasm32 binaries compiled with `target-feature=+simd128`, `simd`, and `allow-wasm32-best-effort-wipe` may use the admitted narrow wasm `simd128` encode and strict-decode backend. | `runtime::backend_report()` tests |
| SIMD status | AVX-512 VBMI, AVX2, SSSE3/SSE4.1, NEON, and narrow wasm `simd128` encode admitted for Standard and URL-safe alphabet families; AVX-512 VBMI, AVX2, SSSE3/SSE4.1, NEON, and narrow wasm `simd128` strict decode admitted for the documented runtime profiles. Wrapped and legacy decode may enter the admitted strict decode backend only after scalar line-profile validation, line-ending compaction, or legacy-whitespace compaction. Strict in-place encode and decode may enter admitted backends only after stack staging. Custom-alphabet, CT secret, big-endian AArch64, RISC-V RVV, broader wasm/browser, and `no_std` acceleration remain prototype-only or scalar. | `docs/SIMD.md` |
| Strict decoding | Default behavior rejects whitespace, mixed alphabets, malformed padding, and non-canonical trailing bits | integration tests |
| Legacy compatibility | Explicit opt-in APIs only | `decode_slice_legacy`, `validate_legacy` |
| Constant-time API | Constant-time-oriented scalar validation/decode and equal-length redacted-buffer comparison helpers exist with isolated dudect-style timing evidence; no formal cryptographic constant-time guarantee | `docs/CONSTANT_TIME.md`, `docs/DUDECT.md` |
| Generated-code review | Assembly evidence is generated by the release gate; manual ct review remains required before stronger wording | `scripts/generate_ct_asm_evidence.sh`, `docs/CT_ASM_REVIEW.md` |
| Cleanup posture | Clear-tail APIs, stream cleanup, `EncodedBuffer`, `DecodedBuffer`, and `SecretBuffer` provide best-effort cleanup; `SecretBuffer` also clears vector spare capacity when wrapping and dropping owned vectors. `wasm32` fails closed by default unless `allow-wasm32-best-effort-wipe` is enabled, and unsupported native architectures fail closed unless `allow-compiler-fence-only-wipe` is enabled. | `SECURITY.md`, `docs/UNSAFE.md`, `scripts/check_wasm_wipe_policy.sh` |
| Fuzzing | Isolated `cargo-fuzz` harnesses outside the published dependency graph | `fuzz/`, `docs/RELEASE_EVIDENCE.md` |
| Miri | Release gate runs Miri when nightly Miri is installed and writes evidence artifacts | `scripts/check_miri.sh`, `target/release-evidence/miri/` |
| Kani | 18 bounded no-default-features harnesses verify cleanly with the Rust `1.90.0` Kani toolchain and `cargo-kani 0.67.0`; incompatible future verifier/toolchain pairs must skip explicitly rather than pretending to prove. | `scripts/check_kani.sh`, `docs/KANI.md` |
| Bounds invariants | Remaining internal indexing is grouped by documented local invariants | `docs/INVARIANTS.md` |
| Audit | RustSec check required | `cargo audit`, `scripts/checks.sh` |
| License policy | `cargo deny` and `cargo license --json` required | `deny.toml`, `scripts/checks.sh` |
| SBOM | SPDX and CycloneDX SBOM generation in release evidence | `scripts/generate-sbom.sh` |
| Reproducibility | Package/build reproducibility check in release gate | `scripts/stable_release_gate.sh` |
| CI bootstrap | Runner-provided `rustup`/`cargo` required; CI refuses `curl \| sh` rustup bootstrap | `scripts/ci_install_rust.sh` |

## Deployment Checks

High-assurance deployments should record `runtime::backend_report()` at process
startup, including `candidate_detection_mode`, and consider enforcing:

```rust
base64_ng::runtime::require_backend_policy(
    base64_ng::runtime::BackendPolicy::HighAssuranceScalarOnly,
)?;
```

Use this policy when deterministic scalar execution matters more than future
acceleration. It requires scalar execution, no detected SIMD candidate, the
`simd` feature disabled, no active accelerated backend, and the conservative
unsafe-boundary flag marked as enforced. It also requires an attested hardware
speculation barrier for the CT result gate. AArch64 reports its CSDB sequence
as `hardware-speculation-barrier-unattested` by default. Deployments that rely
on CSDB must build with the explicit `base64_ng_aarch64_csdb_attested` cfg only
after platform attestation; that path reports
`hardware-speculation-barrier-build-asserted` so logs preserve the distinction
from native target guarantees. The
unsafe-boundary flag is intentionally false when the reserved `simd` feature is
enabled, even if execution remains scalar-only.
For secret-bearing Base64 payloads, combine this policy with the `ct` module
when avoiding future SIMD-induced timing variation is more important than
hardware acceleration.
Treat `candidate_detection_mode=compile-time-target-features` as a build-time
statement, not a runtime CPU attestation. It is used on `no_std` and targets
without `std`-equivalent runtime probing.

## Non-Claims

`base64-ng` currently does not claim:

- formally verified cryptographic constant-time behavior
- formal zeroization of all historical memory copies
- custom-alphabet, CT secret, broader wasm/browser, or `no_std` acceleration
- async/Tokio support in the core crate's inert `tokio` feature
- serde or bytes integration in the core crate
- Kani-complete whole-crate formal verification

Those features remain admission-gated until their evidence is strong enough for
security-sensitive users.

Optional companion crates may integrate with approved ecosystem dependencies,
but they do not change the core `base64-ng` package dependency contract. Use
`base64-ng-subtle` when an application wants `subtle::ConstantTimeEq` at the
protocol comparison boundary without adding `subtle` to the core crate.
