Sanitization 2.1.0 #45
eldryoth
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
sanitization 2.1.0
This release adds an isolated compatibility path for projects migrating from
secrecy0.10 while preserving the stricter exposure and storage contracts ofthe native
sanitizationcontainers.Secrecy compatibility companion
sanitization-secrecysister crate withSecretBox<S>,SecretSlice<S>,SecretString,ExposeSecret, andExposeSecretMut.CloneableSecretsupport and optional plaintext Serde throughSerializableSecret.SecretStringSerde loading to 1 MiB by default and isolate generic,inherently unbounded
SecretBox<T>loading behind the explicitserde-compat-unboundedfeature.new,init_with_mut,init_with, andtry_init_withconstructors. Temporary values used by cloning constructorsare protected by a sanitizing unwind guard, and clone-based constructors
require the explicit
CloneableSecretpartial-destination cleanup contract.try_init_with_mut, runtime-length final-allocation byte-sliceinitialization, exact-capacity no-copy vector transfer, and data-oblivious
equality with explicit call-site declassification.
SecretBoxreference exposure and mutable initialization under every featurecombination. The explicit
hazmat-unrestricted-exposurefeature adds avisibly distinct
UnrestrictedSecretBoxrather than weakening existingtrait implementations through Cargo feature unification.
try_init_with_len_bounded::<MAX, _>so untrusted lengths are rejectedbefore allocation or initialization with typed build/initializer errors.
StringandVecsource capacities during boxedconversion, and sanitize completed destination elements if a later slice
clone unwinds.
unwind cleanup and a mandatory full-initialization assertion before the guard
is disarmed, avoiding allocator-dependent
Veccapacity assertions, andrestrict automatic array clone authorization to reviewed integer arrays.
regression coverage for the clone authorization marker.
Stringwiping to use allocation-wide vectorprovenance, preserving UTF-8 validity during optional multi-pass clearing
and covering excess-capacity strings under Miri.
zeroizeby default and implementZeroize/ZeroizeOnDropforthe compatibility wrapper by delegating to
SecureSanitize.secrecy::...imports canremain unchanged during incremental migration.
coverage, package verification, and release-script integration.
Core support
SecureSanitizeforstr, routing its single unsafe byte-viewconversion through the existing audited wipe backend. Replacing every byte
with ASCII NUL preserves UTF-8 validity and enables fixed boxed strings to be
cleared without allocation.
Security scope
The compatibility wrappers intentionally do not add reference-returning
exposure, cloning, or plaintext serialization to native hardened containers.
They provide baseline boxed ownership and clear-on-drop behavior, not memory
locking, guard pages, canaries, storage-history recovery, or closure-confined
exposure.
SecretStringremains unconditionally cloneable for upstream sourcecompatibility; other custom cloneable values must implement both
SecureSanitizeandCloneableSecret.All six workspace crates are coordinated at version
2.1.0. The runtime keepsan exact dependency on the matching derive crate, and companions retain caret
requirements on the core runtime.
This discussion was created from the release Sanitization 2.1.0.
All reactions