Implement Zeroize for [MaybeUninit<Z>]
#793
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implementing Zeroize for
[MaybeUninit<Z>]
is very helpful IMHO, because it allows to zeroize any custom heap allocated objects by just constructing a slice ofMaybeUninit
(as some of the buffer might not be initialized) and callingzeroize()
on it.I also changed the Vec implementation to zero out the full capacity and not just the uninitialized part, because I don't see any difference between the initialized and the unintialized, if the data in the buffer is secret then we should make sure we zero out all of the buffer.
The downside is that if the Vec contains a primitive(say
Vec<u8>
) then we'll zero the used space twice, so I can see arguments against it (currently the only time I can think this will matter is in Vecs with another indirection, likeVec<Box<Z>>
orVec<&Z>
, and then is there a point in zeroing out those pointers?)So if people disagree on the 2nd commit I can drop it and leave only the first commit.