/*
This module implements a similar API to what the crate `secrecy` provides.
So, why our own implementation?
First `secrecy::Secret<T>` does not put its contents in a `Box`.
Using `Box` is a general recommendation of working with secret data,
because it prevents the compiler from putting it on stack, thus avoiding possible copies on borrow.
Now, one could use `secrecy::Secret<Box<T>>`.
The problem here is that `secrecy::Secret` requires its type parameter to implement `Zeroize`.
This means that for a foreign type `F` (even if it does implement `Zeroize`)
we need to define `impl Zeroize for Box<F>`.
But the compiler does not allow impls of foreign traits on foreign types.
This means that we also need to wrap `F` in a local type, impl `Zeroize` for the wrapper,
and then for the box of the wrapper.
This is too much boilerplate.
Additionally, `secrecy::Secret<Box<T>>` means that after each `expose_secret()`
we will need to deal with opening the `Box` as well.
It's an inconvenience, albeit a minor one.
The situation may improve in the future, and `secrecy` will actually become usable.
*/
use Box;
use ;
/// A container for secret data.
/// Makes the usage of secret data explicit and easy to track,
/// prevents the secret data from being put on stack,
/// and zeroizes the contents on drop.
// No Debug derivation, to avoid exposing the secret data accidentally.
where
T: Zeroize + Clone;
// Alternatively, it could be derived automatically,
// but there's some compilation problem in the macro.
// See https://github.com/RustCrypto/utils/issues/786
// So we're asserting that this object is zeroized on drop, since there is a Drop impl just above.