Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

secrecy: support ZeroizeOnDrop #1181

Open
dima74 opened this issue Apr 22, 2024 · 3 comments
Open

secrecy: support ZeroizeOnDrop #1181

dima74 opened this issue Apr 22, 2024 · 3 comments

Comments

@dima74
Copy link

dima74 commented Apr 22, 2024

Currently Secret<T> wrapper requires T to implement Zeroize. Would be nice to support ZeroizeOnDrop, that is T need to implement either Zeroize or ZeroizeOnDrop. Consider the example which currently doesn't work:

use secrecy::Secret;
use zeroize::{Zeroize, ZeroizeOnDrop};

pub struct SecretKey([u8; 32]);

impl ZeroizeOnDrop for SecretKey {}
impl Drop for SecretKey {
    fn drop(&mut self) {
        self.0.zeroize();
    }
}

struct Config {
    // doesn't work
    key: Secret<SecretKey>,
}

Would be helpful in case library implements only ZeroizeOnDrop and not Zeroize (e.g. ed25519-dalek)


Probably this can be done similar to how #[derive(ZeroizeOnDrop)] is implemented

@tony-iqlusion
Copy link
Member

What value does Secret provide for a ZeroizeOnDrop type, which already handles its own zeroization?

@dima74
Copy link
Author

dima74 commented Apr 22, 2024

@tony-iqlusion first two from documentation:

  • Make secret access explicit and easy-to-audit via the ExposeSecret trait
  • Prevent accidental leakage of secrets via channels like debug logging

@tony-iqlusion
Copy link
Member

We could potentially add a separate wrapper type which doesn't have a Zeroize bound, but that's the best we could do.

Most types which impl ZeroizeOnDrop intentionally do not impl Zeroize so as to avoid "use after zeroize" bugs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants