impl Zeroize for BytesMut (optional)#335
Conversation
`zeroize` is a popular Rust crate for securely zeroing memory: https://crates.io/crates/zeroize (I am the author) Presently it's possible to use `Zeroize` with `BytesMut` via `DerefMut` coercion (`Zeroize` is impl'd for `slice::IterMut`). The implementation in this commit is more complete in that it handles clearing data in the remaining capacity, in the event that it previously contained secrets. `zeroize` presently has a `bytes-preview` feature (which depends on `bytes` 4.0) which provides this implementation: https://docs.rs/zeroize/1.0.0/zeroize/#bytes-preview-feature-zeroize-support-for-bytesmut I'd like to either upstream that implementation, i.e. this commit, or drop the `bytes-preview` feature in `zeroize` as otherwise it seems deref coercion is sufficient to get a "good enough" implementation (and anyone who wants something better can make a newtype).
|
My gut feeling is to reduce the 3rd party dependencies. @carllerche ?
That makes sense from a maintenance point of view. 👍 |
|
@seanmonstar one semi-related thing which I don't think can be solved without https://github.com/iqlusioninc/crates/blob/544abcc/secrecy/src/bytes.rs#L57 ...or in brief: in a However, it appears I'm not sure the best way to solve this. I've thought about adding a |
- Removes the `bytes-preview` feature from `zeroize` - Upgrades `secrecy` to use `bytes` v0.5 Now that `bytes` v0.5 is out, I've opened a PR to upstream the `Zeroize` impl for `BytesMut`: tokio-rs/bytes#335 Unfortunately it's no-longer possible to impl `Zeroize` for `Bytes` as of `bytes` v0.5, as the `try_mut` method was dropped in this PR: tokio-rs/bytes#298 I have brought this up on the first PR. In the meantime, this vendors the previous `BytesMut` impl of `Zeroize` into `secrecy`'s `SecretBytesMut` type, and drops `SecretBytes` as it's no-longer possible to implement.
|
If we expose it, you should be able to define your own |
- Removes the `bytes-preview` feature from `zeroize` - Upgrades `secrecy` to use `bytes` v0.5 Now that `bytes` v0.5 is out, I've opened a PR to upstream the `Zeroize` impl for `BytesMut`: tokio-rs/bytes#335 Unfortunately it's no-longer possible to impl `Zeroize` for `Bytes` as of `bytes` v0.5, as the `try_mut` method was dropped in this PR: tokio-rs/bytes#298 I have brought this up on the first PR. In the meantime, this vendors the previous `BytesMut` impl of `Zeroize` into `secrecy`'s `SecretBytesMut` type, and drops `SecretBytes` as it's no-longer possible to implement.
|
@carllerche that might work. I'd have to play with it. What I'd like to do is be able to give out references to https://docs.rs/secrecy/0.5.1/secrecy/struct.SecretBytes.html#implementations If I can still do that without any modifications to |
|
Ok, I'm going to close this for now. We are trying to prune external deps (even optional) to try to reach stability. |
This is done due to the recent Secrecy breaking changes induced by Bytes 0.5 tokio-rs/bytes#335 iqlusioninc/crates#301
zeroizeis a popular Rust crate for securely zeroing memory:https://crates.io/crates/zeroize
(I am the author)
Presently it's possible to use
ZeroizewithBytesMutviaDerefMutcoercion (Zeroizeis impl'd forslice::IterMut).The implementation in this PR is more complete in that it handles clearing data in the remaining capacity, in the event that it previously contained secrets.
zeroizepresently has abytes-previewfeature (which depends onbytes4.0) which provides this implementation:https://docs.rs/zeroize/1.0.0/zeroize/#bytes-preview-feature-zeroize-support-for-bytesmut
I'd like to either upstream that implementation, i.e. this PR, and/or drop the
bytes-previewfeature inzeroizeas otherwise it seems deref coercion is sufficient to get a "good enough" implementation (and anyone who wants something better can make a newtype which does what's in the impl in this commit, in the event this PR doesn't get merged).tl;dr: this PR provides an optimal implementation of
Zeroize, but if adding an optional dependency is too onerous, no worries - what we get through deref coercion is "good enough"