Start 0.10 audit cycle

Author: eldryoth

CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## 0.10.0-alpha.0 - Unreleased
+
+- Started the next development cycle after the `0.9.0` release.
+- Added a dedicated public API audit checklist for the `v0.10`
+  release-candidate audit-preparation milestone.
+
 ## 0.9.0 - 2026-05-17
 
 - Started the next development cycle after the `0.8.0` release.

Cargo.lock

@@ -1,6 +1,6 @@
 [package]
 name = "base64-ng"
-version = "0.9.0"
+version = "0.10.0-alpha.0"
 edition = "2024"
 rust-version = "1.95"
 license = "MIT OR Apache-2.0"

Cargo.toml

@@ -6,7 +6,8 @@ The crate starts conservative: a small scalar implementation, strict RFC 4648 be
 
 ## Current Status
 
-The current public release is `0.9.0`.
+The current public release is `0.9.0`. The development branch is
+`0.10.0-alpha.0`.
 
 Implemented now:
 
@@ -47,9 +48,8 @@ Implemented now:
 Planned behind admission evidence:
 
 - Admitted AVX2, AVX-512, SSSE3/SSE4.1, ARM NEON, and wasm `simd128`
-  fast paths after the SIMD admission evidence is complete. The `0.9.0`
-  release remains scalar-only because that full evidence package has not
-  landed.
+  fast paths after the SIMD admission evidence is complete. Current `0.10`
+  development remains scalar-only unless that full evidence package lands.
 - Async streaming wrappers only after the `tokio` feature passes the
   dependency and cancellation-safety admission bar in [docs/ASYNC.md](docs/ASYNC.md).
 - Optional `serde` or `bytes` integration only if a concrete use case clears

README.md

@@ -0,0 +1,64 @@
+# Public API Audit
+
+This document tracks the `v0.10` audit-preparation milestone. The goal is to
+enter the `v1.0` candidate series with a small, explicit, security-reviewed
+public surface. The audit favors removing or documenting ambiguous APIs over
+adding convenience.
+
+## Audit Rules
+
+- Keep strict, canonical decoding as the default.
+- Keep legacy, wrapped, profile-specific, and constant-time-oriented behavior
+  explicit in names or modules.
+- Do not add broad conversion traits that hide alphabet, padding, wrapping,
+  allocation, or secret-handling policy.
+- Do not admit optional ecosystem dependencies without a written dependency
+  admission record.
+- Do not admit active SIMD dispatch through an API audit; SIMD remains governed
+  by the dedicated SIMD admission manifest.
+- Treat any API that exposes owned bytes or backing arrays as a security
+  boundary that must be documented.
+- Prefer caller-owned output APIs and recoverable errors for untrusted input.
+
+## Public Surface Under Review
+
+| Area | Status | Notes |
+| --- | --- | --- |
+| Engine constants and `Engine<A, PAD>` | review pending | Confirm strict/default semantics and constructor naming before `v1.0`. |
+| `Profile<A, PAD>` and named profiles | review pending | Freeze MIME, PEM, bcrypt-style, `crypt(3)`-style, wrapping, and padding behavior. |
+| Length helpers | review pending | Confirm all public helpers stay recoverable and panic-free for untrusted sizes. |
+| Slice encode/decode APIs | review pending | Confirm buffer sizing, clear-tail variants, and error semantics. |
+| In-place APIs | review pending | Confirm decode-to-front and encode-to-back contracts are clear. |
+| Validation-only APIs | review pending | Confirm validate/decode agreement across strict, legacy, wrapped, and ct paths. |
+| Stack-backed buffers | review pending | Confirm exposed-array escape hatches and cleanup boundaries are documented. |
+| `SecretBuffer` | review pending | Confirm redaction, cleanup limits, comparison semantics, and ownership escape hatches. |
+| `ct` module | review pending | Confirm non-claim wording and opaque error behavior remain explicit. |
+| `stream` module | review pending | Confirm fail-closed behavior, retry semantics, state helpers, and recovery helpers. |
+| Runtime backend reporting | review pending | Confirm scalar-only posture and stable log identifiers. |
+| Feature flags | review pending | Confirm `tokio`, `kani`, `fuzzing`, and `simd` remain inert or reserved as documented. |
+| Error types | review pending | Confirm variants and indexes are stable enough for downstream diagnostics. |
+| Macros and custom alphabets | review pending | Confirm compile-time validation and custom-alphabet performance/security tradeoffs. |
+
+## `v1.0` Admission Questions
+
+- Is the API name explicit about strict, legacy, wrapped, profile, or
+  constant-time-oriented behavior?
+- Can the caller size memory before using the API?
+- Does the API have a caller-owned buffer form when it can allocate?
+- Does the API expose a clear cleanup boundary for sensitive data?
+- Does the API keep malformed input recoverable instead of panicking?
+- Does the API commit to behavior that future SIMD backends can reproduce
+  exactly?
+- Does the API require dependency admission or feature-policy documentation?
+
+## Initial `v0.10` Direction
+
+- Keep async/Tokio, serde, bytes, zeroize, subtle, property-test, and
+  Criterion-style integrations out unless a concrete admission record is
+  written.
+- Keep `ct` documented as constant-time-oriented rather than formally
+  cryptographic unless verification evidence improves during the `v0.10` to
+  `v0.12` candidate series.
+- Keep active dispatch scalar-only until SIMD admission evidence is complete.
+- Focus implementation work on audit findings, documentation gaps, tests, and
+  evidence rather than new feature breadth.

docs/API_AUDIT.md

@@ -1,8 +1,8 @@
 # SIMD Admission Policy
 
-`base64-ng` is intentionally scalar-only in the `0.9.0` release because no
-complete SIMD admission evidence package has landed. The crate uses
-`#![deny(unsafe_code)]` and permits reviewed
+`base64-ng` is intentionally scalar-only in the `0.10.0-alpha.0` development
+branch unless a complete SIMD admission evidence package lands in the same
+release series. The crate uses `#![deny(unsafe_code)]` and permits reviewed
 `allow(unsafe_code)` exceptions only for volatile wipe helpers in `src/lib.rs`
 and the private `src/simd.rs` boundary. The `simd` feature remains reserved
 until architecture-specific code has enough evidence to justify enabling it.
@@ -61,10 +61,10 @@ weakening the scalar trust base.
 - Unit tests compare dispatch behavior against the scalar reference for
   canonical inputs, malformed inputs, and undersized output buffers.
 - The `simd` feature does not enable accelerated code yet.
-- The `0.9.0` release remains scalar-only because the SIMD admission manifest,
-  scalar differential tests, fuzz evidence, unsafe inventory, architecture
-  evidence, benchmark evidence, and release wording were not updated together
-  for an admitted backend.
+- Current `0.10` development remains scalar-only unless the SIMD admission
+  manifest, scalar differential tests, fuzz evidence, unsafe inventory,
+  architecture evidence, benchmark evidence, and release wording are updated
+  together.
 - CI checks the reserved `simd` feature in `no_std` mode for x86_64, aarch64,
   FreeBSD, wasm32, and Cortex-M targets.
 - Performance claims must be backed by local benchmark evidence, not roadmap

docs/SIMD.md

@@ -10,8 +10,9 @@ the admitted implementation.
 - Admitted backends: none.
 - Active backend: scalar only.
 - Public performance claims: none.
-- Release status: `0.9.0` remains scalar-only because this manifest has not
-  been updated with a complete backend admission evidence package.
+- Release status: current `0.10.0-alpha.0` development remains scalar-only
+  unless this manifest is updated with a complete backend admission evidence
+  package in the same release series.
 
 ## Required For Every Admitted Backend
 

docs/SIMD_ADMISSION.md

@@ -5,4 +5,4 @@ edition = "2024"
 publish = false
 
 [dependencies]
-base64-ng = { path = "..", version = "0.9.0-alpha.0", default-features = false }
+base64-ng = { path = "..", version = "0.10.0-alpha.0", default-features = false }