secrecy: Allow opting in to PartialEq/Eq implementations for secrets for testing

[steven-joruk]

I would find it useful when unit testing equivalence of values which contain secrets.

I can work around it by manually implementing the traits for my structs which contain secrets, but maybe others would find this useful as well.

Perhaps it should be an opt-in feature flag so that it could support more test project configurations?

[tony-iqlusion]

How about subtle::ConstantTimeEq as a safe alternative?

It's slightly more cumbersome in that you have to import a trait and use Into to coerce subtle::Choice into a boolean, but it would avoid exposing unsafe APIs just for testing.

[marccarre]

@steven-joruk, which workaround did you end up using? Mind sharing an example? 🙇🏻‍♂️
@tony-iqlusion, could you share an example of what you'd have in mind for the case of implementing PartialEq/Eq using subtle::Choice? 🙇🏻‍♂️

[Bauxitedev]

Unfortunately, due to the orphan trait rule, I couldn't find a nice workaround for this, so I just made my own wrapper type and used that instead.

use secrecy::{
    ExposeSecret, Secret, Zeroize,
};

/// Secret<T> wrapper that impls PartialEq and Eq (so you can use it in BTreeSets and such)
pub struct SecretWrapper<T>(pub Secret<T>)
where
    T: Zeroize;

impl<T> SecretWrapper<T>
where
    T: Zeroize,
{
    pub fn new(value: T) -> Self {
        Self(Secret::new(value))
    }
}

impl<T> Eq for SecretWrapper<T> where T: Zeroize + Eq {}
impl<T> PartialEq for SecretWrapper<T>
where
    T: Zeroize + PartialEq,
{
    fn eq(&self, other: &Self) -> bool {
        self.expose_secret() == other.expose_secret()
    }
}

You'll need to impl any other traits you may need (Clone/Debug/etc)