Prepare 1.0.3

Author: eldryoth

.github/workflows/ci.yml

@@ -25,18 +25,18 @@ jobs:
 
     steps:
       - name: Checkout repository
-        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
+        uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
 
       - name: Install Rust toolchain
         run: rustup show
 
       - name: Cache Rust build output
-        uses: Swatinem/rust-cache@e18b497796c12c097a38f9edb9d0641fb99eee32 # v2
+        uses: Swatinem/rust-cache@c19371144df3bb44fab255c43d04cbc2ab54d1c4 # v2.9.1
         with:
           cache-on-failure: true
 
       - name: Install security tools
-        uses: taiki-e/install-action@873c7452cadb7c034694a1282227095d93fbdf92 # v2.79.14
+        uses: taiki-e/install-action@0631aa6515c7d545823c67cfae7ef4fc7f490154 # v2.81.8
         with:
           tool: cargo-deny,cargo-audit
 

CHANGELOG.md

@@ -1,5 +1,22 @@
 # Changelog
 
+## 1.0.3
+
+- Bumped the crate to `1.0.3`.
+- Hardened encoded-output error paths by keeping encoder output in a
+  `Zeroizing<Vec<u8>>` until successful return, so partially encoded bytes are
+  scrubbed on encoder errors.
+- Added debug/test assertions for exact identity, cache-key, and XXH3 chunk
+  preimage capacities so future edits cannot silently introduce reallocations
+  before zeroization.
+- Redacted `AvatarBuilder` namespace tenant and style-version values from
+  `Debug` output in addition to the identity input.
+- Updated `docs/SECURITY_CONTROLS.md` to accurately describe accepted
+  upper-digest-byte visual parameter usage for `1.x` visual stability.
+- Updated GitHub Actions pins to `actions/checkout` `v6.0.3`,
+  `Swatinem/rust-cache` `v2.9.1`, and `taiki-e/install-action` `v2.81.8`.
+- Removed the temporary pentest report from the tree.
+
 ## 1.0.2
 
 - Bumped the crate to `1.0.2`.

Cargo.lock

@@ -1,6 +1,6 @@
 [package]
 name = "hashavatar"
-version = "1.0.2"
+version = "1.0.3"
 edition = "2024"
 rust-version = "1.90"
 description = "Stable deterministic procedural avatars in Rust with configurable identity hashing, WebP, optional PNG/JPEG/GIF, and SVG export"

Cargo.toml

@@ -29,7 +29,7 @@ The crate starts conservative: validated avatar dimensions, bounded identity inp
 
 ## Current Status
 
-The current crate version is `1.0.2`.
+The current crate version is `1.0.3`.
 
 Implemented now:
 
@@ -106,7 +106,7 @@ to split it.
 The minimum supported Rust version is Rust `1.90.0`. New deployments should
 prefer the latest stable Rust; as of May 29, 2026, that is Rust `1.96.0`.
 
-Compatibility evidence for `1.0.2`:
+Compatibility evidence for `1.0.3`:
 
 | Rust | Local Evidence |
 | --- | --- |
@@ -127,36 +127,36 @@ Optional hash modes are mutually exclusive, so `hashavatar` cannot use a single
 
 ```toml
 [dependencies]
-hashavatar = "1.0.2"
+hashavatar = "1.0.3"
 ```
 
 Optional identity hash modes and extra raster encoders are disabled by default.
 Hash modes are mutually exclusive, so enable at most one of `blake3` or `xxh3`:
 
 ```toml
 [dependencies]
-hashavatar = { version = "1.0.2", features = ["blake3"] }
+hashavatar = { version = "1.0.3", features = ["blake3"] }
 ```
 
 Enable additional raster formats explicitly:
 
 ```toml
 [dependencies]
-hashavatar = { version = "1.0.2", features = ["png", "jpeg", "gif"] }
+hashavatar = { version = "1.0.3", features = ["png", "jpeg", "gif"] }
 ```
 
 Or enable every optional raster encoder at once:
 
 ```toml
 [dependencies]
-hashavatar = { version = "1.0.2", features = ["all-formats"] }
+hashavatar = { version = "1.0.3", features = ["all-formats"] }
 ```
 
 Enable string serialization/deserialization for public style enums:
 
 ```toml
 [dependencies]
-hashavatar = { version = "1.0.2", features = ["serde"] }
+hashavatar = { version = "1.0.3", features = ["serde"] }
 ```
 
 Combine these as needed, for example `features = ["blake3", "png", "serde"]`.
@@ -519,7 +519,7 @@ your namespace style version when intentionally migrating output.
 
 ```toml
 [dependencies]
-hashavatar = { version = "1.0.2", features = ["blake3"] }
+hashavatar = { version = "1.0.3", features = ["blake3"] }
 ```
 
 ```rust
@@ -547,7 +547,7 @@ assert!(svg.contains("alien avatar"));
 
 ```toml
 [dependencies]
-hashavatar = { version = "1.0.2", features = ["xxh3"] }
+hashavatar = { version = "1.0.3", features = ["xxh3"] }
 ```
 
 ```rust

README.md

@@ -34,8 +34,12 @@
   `hashavatar` cannot zeroize those codec-owned buffers. High-assurance
   deployments should prefer WebP or PNG.
 - Procedural RNG seeding uses 256 bits from the second half of the identity
-  digest, separate from the lower digest bytes commonly used for direct visual
-  parameters.
+  digest. Most direct visual parameter lookups use lower digest bytes, but some
+  established renderers also use selected upper digest bytes for visible
+  geometry. This is accepted for `1.x` visual stability: avatars are
+  digest-derived public artifacts, and removing those lookups would change
+  golden output. Callers that treat identifiers as sensitive should prefer
+  SHA-512 or BLAKE3 over XXH3 and follow the timing/output-size guidance below.
 - The temporary 256-bit RNG seed copy is stored in `zeroize::Zeroizing`, so the
   digest-derived seed copy is scrubbed on scope exit. The final value passed to
   `StdRng::from_seed` is also held in a `Zeroizing` guard before the copy into
@@ -53,7 +57,8 @@
 - `AvatarIdentity` has a redacted `Debug` implementation so accidental
   `{:?}` logging does not print the raw digest.
 - `AvatarBuilder` has a redacted `Debug` implementation so accidental builder
-  logging does not print the raw identity input.
+  logging does not print the raw identity input, tenant, or style-version
+  namespace values.
 - `AvatarIdentity::cache_key()` derives an opaque display key by hashing the
   internal identity digest under a cache-key domain instead of returning raw
   digest bytes. Cache keys are still stable correlators for the same identity
@@ -75,11 +80,13 @@
   BLAKE3 hasher and XOF reader after deriving the 64-byte digest. Tests assert
   these upstream zeroization traits remain available.
 - Identity hash preimage allocation is sized from the tenant, style-version,
-  and identity input lengths. The crate bounds and zeroizes those temporary
-  buffers, but it does not hide input length from the allocator, OS-level heap
-  profilers, or other same-process memory-observation tools. Very
-  high-assurance callers that treat identifier length as sensitive should
-  normalize or pad identifiers to a fixed length before calling this crate.
+  and identity input lengths. Debug/test builds assert that preimage buffers do
+  not reallocate before zeroization, so future component-size drift is caught by
+  CI. The crate bounds and zeroizes those temporary buffers, but it does not
+  hide input length from the allocator, OS-level heap profilers, or other
+  same-process memory-observation tools. Very high-assurance callers that treat
+  identifier length as sensitive should normalize or pad identifiers to a fixed
+  length before calling this crate.
 - The optional XXH3-128 mode derives the crate's 64-byte identity digest by
   hashing four domain-separated chunks. Each chunk temporarily copies the
   bounded preimage into a zeroized buffer, so peak preimage memory is higher
@@ -93,7 +100,9 @@
   binary must configure and test `getrandom` for their target explicitly.
 - Encode APIs wrap temporary owned raster buffers in RAII zeroization guards, so
   pixel data is cleared during normal returns, encoder errors, and unwinding
-  panics. JPEG export also wraps the temporary RGB flattening buffer in
+  panics. Encoded output is accumulated in a `Zeroizing<Vec<u8>>` until
+  successful return, so partially encoded bytes are scrubbed on encoder errors.
+  JPEG export also wraps the temporary RGB flattening buffer in
   `zeroize::Zeroizing`. Returned encoded bytes and images returned by render
   APIs are caller-owned and must be cleared by the caller if their environment
   requires that. The README includes `zeroize` examples for returned `Vec<u8>`

docs/SECURITY_CONTROLS.md

@@ -0,0 +1,30 @@
+# hashavatar 1.0.3
+
+`1.0.3` is a security-hardening and CI maintenance release for `hashavatar`.
+
+## Security And Hardening
+
+- Encoded output is now accumulated in a `Zeroizing<Vec<u8>>` until successful
+  return. If an encoder returns an error after writing partial bytes, those
+  partially encoded bytes are scrubbed before being dropped.
+- Identity, cache-key, and XXH3 chunk preimage builders now assert exact
+  capacity in debug/test builds. This catches future component-size drift that
+  would otherwise allow reallocations before zeroization.
+- `AvatarBuilder` debug output now redacts namespace tenant and style-version
+  values, not only the raw identity input.
+- Security controls now document the accepted `1.x` visual-stability tradeoff
+  that some established renderers use selected upper digest bytes directly for
+  visible geometry.
+
+## CI
+
+- Updated pinned GitHub Actions:
+  - `actions/checkout` to `v6.0.3`
+  - `Swatinem/rust-cache` to `v2.9.1`
+  - `taiki-e/install-action` to `v2.81.8`
+
+## Compatibility
+
+- No intentional avatar visual fingerprint changes.
+- No public API removals.
+- No dependency version changes.

docs/release-notes/RELEASE_NOTES_1.0.3.md

@@ -8,7 +8,7 @@ publish = false
 cargo-fuzz = true
 
 [dependencies]
-hashavatar = { path = "..", version = "1.0.2", features = ["fuzzing"] }
+hashavatar = { path = "..", version = "1.0.3", features = ["fuzzing"] }
 libfuzzer-sys = "0.4"
 roxmltree = "0.21.1"