chore(deps): bump the rust-patch group with 2 updates

[dependabot]

Bumps the rust-patch group with 2 updates: sanitization and sanitization-crypto-interop.

Updates sanitization from 2.0.1 to 2.0.3

Release notes

Sourced from sanitization's releases.

Sanitization 2.0.3

sanitization 2.0.3

This patch release closes the policy-ordering gap for runtime-length secret decoders and generators.

Protection before materialization

LockedSecretVec and GuardedSecretVec now provide policy-aware in-place constructors for exact-length and capacity-bounded output. Every control marked Required is established before the fill callback runs. This lets decoders, RNGs, KDFs, and protocol implementations write directly into final protected storage without first materializing plaintext under a degraded mapping.

Explicit try_from_capacity_bounded_with_protection constructors reject untrusted decoder capacities above an application maximum before mapping or callback execution. The unbounded variants are documented for trusted, already-limited capacities only.

For applications that need the maximum to remain enforced after construction, this release also adds const-generic bounded mapped owners:

• BoundedLockedSecretVec<MAX> and BoundedLockedSecretString<MAX>;
• BoundedGuardedSecretVec<MAX> and BoundedGuardedSecretString<MAX>.

These wrappers keep the underlying growable owner private and reject every oversized construction, append, or replacement before allocation or generator execution. BoundedMappedSecretError<E> keeps limit, arithmetic-overflow, integrity, and platform-operation failures distinct. The existing bounded constructors remain useful as one-shot admission controls when later growth is intentionally permitted.

The callback receives exactly the requested public capacity. This remains true when guard-page allocation rounds its internal writable payload to a larger page boundary. Success clears the entire unreported tail; callback failure and excessive reported lengths clear the mapping before returning.

LockedSecretString and GuardedSecretString expose matching constructors. They validate the initialized prefix as UTF-8 without reallocating and clear invalid payloads before returning an error.

Typed integrity boundary

ProtectedSecretFillError<E> distinguishes required-protection setup, callback, canary-integrity, capacity-limit, and reported-length failures. ProtectedSecretTextFillError<E> adds UTF-8 validation failure.

When canaries are enabled, the suffix canary is placed at the caller-visible capacity boundary while the fill callback runs and verified immediately after it returns. This catches an unsafe external decoder writing past its advertised

... (truncated)

Changelog

Sourced from sanitization's changelog.

2.0.3

• Add policy-aware, in-place runtime-length constructors for LockedSecretVec and GuardedSecretVec, ensuring every required runtime control is established before a decoder, RNG, KDF, or protocol callback can materialize secret bytes.
• Add matching protected fill constructors for LockedSecretString and GuardedSecretString, with clear-on-error UTF-8 validation.
• Introduce ProtectedSecretFillError<E> and ProtectedSecretTextFillError<E> so protection, callback, integrity, length, and UTF-8 failures remain distinguishable.
• Add bounded policy-aware constructors for locked and guarded byte and UTF-8 storage. Oversized untrusted capacities are rejected before mapping or fill callback execution through a distinct CapacityLimit error.
• Add BoundedLockedSecretVec<MAX>, BoundedGuardedSecretVec<MAX>, BoundedLockedSecretString<MAX>, and BoundedGuardedSecretString<MAX> for a permanent lifetime bound rather than constructor-only admission. Their inner growable owners cannot be extracted, and every safe append or replacement is checked before allocation or generator execution.
• Add BoundedMappedSecretError<E> to distinguish permanent-limit rejection, length overflow, canary corruption, and backend operation failure.
• Restrict fill callbacks to the requested public capacity even when a guarded mapping has a larger page-rounded payload, and clear the complete unreported tail before returning success.
• Place and verify the suffix canary at the advertised capacity boundary while a callback runs, detecting an unsafe decoder write past that boundary before moving the canary to the initialized length.
• Erase the initial length-zero suffix canary and the caller-visible payload before relocating the canary and invoking protected dynamic fill callbacks, preventing disclosure of canary material to decoder or generator code.
• Clarify that mapped native and subtle comparison timing is conditioned on intact canaries; corruption is a public operational failure that returns a false choice before the payload comparison.
• Exercise temporary capacity-boundary canary verification through allocation-provenance-safe fault injection immediately after protected fill callbacks return.
• Add native and Miri-model regression coverage for policy ordering, degraded setup rejection, typed failures, tail handling, UTF-8 rejection, and canary corruption.
• Make canary and tail-erasure regressions deterministic without depending on the host's memory-lock quota, and make the high-assurance decoder example require dump and fork exclusion before materialization.
• Coordinate all five workspace crates and the exact runtime/derive dependency at version 2.0.3.

2.0.2

• Add a cfg(all(miri, test)) aligned-allocation backend for native LockedSecretBytes, LockedSecretVec, LockedSecretString, and SecretPool lifecycle tests so core Miri coverage can exercise those state

... (truncated)

Commits

• ffcb211 Record 2.0.3 security review
• d9578b2 Restore protected fill boundary regression tests
• de9288c Prevent canary exposure during mapped initialization
• f4cec06 Add permanently bounded mapped secrets
• dd937fe Bound protected dynamic secret allocation
• d71744f Add policy-aware dynamic secret initialization
• e4149d6 Add 2.0.2 pentest report
• 8755f99 Harden reseal failure test invariant
• 0465c80 Preserve failed reseal state in cleanup test
• 505c855 Harden page-sealed cleanup fault tests
• Additional commits viewable in compare view

Updates sanitization-crypto-interop from 2.0.1 to 2.0.3

Release notes

Sourced from sanitization-crypto-interop's releases.

Sanitization 2.0.3

sanitization 2.0.3

This patch release closes the policy-ordering gap for runtime-length secret decoders and generators.

Protection before materialization

LockedSecretVec and GuardedSecretVec now provide policy-aware in-place constructors for exact-length and capacity-bounded output. Every control marked Required is established before the fill callback runs. This lets decoders, RNGs, KDFs, and protocol implementations write directly into final protected storage without first materializing plaintext under a degraded mapping.

Explicit try_from_capacity_bounded_with_protection constructors reject untrusted decoder capacities above an application maximum before mapping or callback execution. The unbounded variants are documented for trusted, already-limited capacities only.

For applications that need the maximum to remain enforced after construction, this release also adds const-generic bounded mapped owners:

• BoundedLockedSecretVec<MAX> and BoundedLockedSecretString<MAX>;
• BoundedGuardedSecretVec<MAX> and BoundedGuardedSecretString<MAX>.

These wrappers keep the underlying growable owner private and reject every oversized construction, append, or replacement before allocation or generator execution. BoundedMappedSecretError<E> keeps limit, arithmetic-overflow, integrity, and platform-operation failures distinct. The existing bounded constructors remain useful as one-shot admission controls when later growth is intentionally permitted.

The callback receives exactly the requested public capacity. This remains true when guard-page allocation rounds its internal writable payload to a larger page boundary. Success clears the entire unreported tail; callback failure and excessive reported lengths clear the mapping before returning.

LockedSecretString and GuardedSecretString expose matching constructors. They validate the initialized prefix as UTF-8 without reallocating and clear invalid payloads before returning an error.

Typed integrity boundary

ProtectedSecretFillError<E> distinguishes required-protection setup, callback, canary-integrity, capacity-limit, and reported-length failures. ProtectedSecretTextFillError<E> adds UTF-8 validation failure.

When canaries are enabled, the suffix canary is placed at the caller-visible capacity boundary while the fill callback runs and verified immediately after it returns. This catches an unsafe external decoder writing past its advertised

... (truncated)

Changelog

Sourced from sanitization-crypto-interop's changelog.

2.0.3

• Add policy-aware, in-place runtime-length constructors for LockedSecretVec and GuardedSecretVec, ensuring every required runtime control is established before a decoder, RNG, KDF, or protocol callback can materialize secret bytes.
• Add matching protected fill constructors for LockedSecretString and GuardedSecretString, with clear-on-error UTF-8 validation.
• Introduce ProtectedSecretFillError<E> and ProtectedSecretTextFillError<E> so protection, callback, integrity, length, and UTF-8 failures remain distinguishable.
• Add bounded policy-aware constructors for locked and guarded byte and UTF-8 storage. Oversized untrusted capacities are rejected before mapping or fill callback execution through a distinct CapacityLimit error.
• Add BoundedLockedSecretVec<MAX>, BoundedGuardedSecretVec<MAX>, BoundedLockedSecretString<MAX>, and BoundedGuardedSecretString<MAX> for a permanent lifetime bound rather than constructor-only admission. Their inner growable owners cannot be extracted, and every safe append or replacement is checked before allocation or generator execution.
• Add BoundedMappedSecretError<E> to distinguish permanent-limit rejection, length overflow, canary corruption, and backend operation failure.
• Restrict fill callbacks to the requested public capacity even when a guarded mapping has a larger page-rounded payload, and clear the complete unreported tail before returning success.
• Place and verify the suffix canary at the advertised capacity boundary while a callback runs, detecting an unsafe decoder write past that boundary before moving the canary to the initialized length.
• Erase the initial length-zero suffix canary and the caller-visible payload before relocating the canary and invoking protected dynamic fill callbacks, preventing disclosure of canary material to decoder or generator code.
• Clarify that mapped native and subtle comparison timing is conditioned on intact canaries; corruption is a public operational failure that returns a false choice before the payload comparison.
• Exercise temporary capacity-boundary canary verification through allocation-provenance-safe fault injection immediately after protected fill callbacks return.
• Add native and Miri-model regression coverage for policy ordering, degraded setup rejection, typed failures, tail handling, UTF-8 rejection, and canary corruption.
• Make canary and tail-erasure regressions deterministic without depending on the host's memory-lock quota, and make the high-assurance decoder example require dump and fork exclusion before materialization.
• Coordinate all five workspace crates and the exact runtime/derive dependency at version 2.0.3.

2.0.2

• Add a cfg(all(miri, test)) aligned-allocation backend for native LockedSecretBytes, LockedSecretVec, LockedSecretString, and SecretPool lifecycle tests so core Miri coverage can exercise those state

... (truncated)

Commits

• ffcb211 Record 2.0.3 security review
• d9578b2 Restore protected fill boundary regression tests
• de9288c Prevent canary exposure during mapped initialization
• f4cec06 Add permanently bounded mapped secrets
• dd937fe Bound protected dynamic secret allocation
• d71744f Add policy-aware dynamic secret initialization
• e4149d6 Add 2.0.2 pentest report
• 8755f99 Harden reseal failure test invariant
• 0465c80 Preserve failed reseal state in cleanup test
• 505c855 Harden page-sealed cleanup fault tests
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[dependabot]

Labels

The following labels could not be found: dependencies, rust. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.