zeroize: provide a Vec with zero-on-realloc? about crates HOT 3 CLOSED

Yep, I should probably call out Vec explicitly in the docs under the caveats section in regard to things which make copies. I have definitely ranted about it offline quite a bit, and wondered if providing Zeroize impls for these types, including String, is a good idea or not. As this crate is effectively "best effort", the intent is to zero out as many copies as possible with the assumption fewer copies is better, leaving avoiding making them in the first place as an exercise to the end user.

Is it possible to provide a Vec-like type which zeros the old data during reallocation?

One option is to use heapless::Vec and heapless::String. Otherwise I think functionality beyond the core zeroization behavior is best left to crates which consume zeroize and leverage it as a zeroing backend.

I think the simplest way to avoid problems is to wrap Vec/String in a tuple struct/newtype which is ZeroizeOnDrop and always initialized (even vicariously) with the correct initial capacity so as to avoid reallocation, then only permitting immutable borrows of its contents, which would strategically eliminate the potential for reallocation and ensure it doesn't happen on initialization. Such a type seems like a good thing for a higher-level crate to provide.

I might take a crack at making such a crate. I've been thinking about it for awhile.

from crates.

I recently created secrecy, which seems like an appropriate place for these sorts of types:

https://github.com/iqlusioninc/crates/tree/develop/secrecy

I'd like to add SecretVec and a SecretString (which is backed by SecretVec)

from crates.

secrecy v0.3 now contains SecretVec and SecretString types (which are really just aliases for Secret<String> and Secret<Vec>, which I think addresses the original goals of this issue by both preventing mutations once instantiated as well as ensuring zeroize-on-drop:

https://docs.rs/secrecy/0.3.1/secrecy/type.SecretVec.html

from crates.