You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
zeroize_derive: Require zeroize(drop) or zeroize(no_drop)
The previous version of `zeroize` (v0.8) automatically derived a `Drop`
impl unless `zeroize(no_drop)` was passed explicitly.
This felt like the right thing to do at first, however it turns out
there are a lot of cases in practice where it's undesirable to derive
`Drop` by default, e.g. on any `Copy` type. This was encountered
in-practice retrofitting `zeroize` into the `curve25519-dalek` crate.
This changes the custom derive impl to require an explicit decision in
the form of an attribute as to whether a `Drop` impl should be derived
or not.
Going forward (i.e. in `zeroize` 1.0) deriving `Drop` will need to be
explicitly declared as `zeroize(drop)`, and the need to explicitly
specify `zeroize(no_drop)` can be removed, meaning no `Drop` impl will
be derived by default. However, since previous users of `zeroize` v0.8
will be expecting `Drop` by default, this change makes it an explicit
decision, so as to avoid people expecting to get a `Drop` impl by
default not actually receiving one.
Once crates.io stats show `zeroize` v0.8 is no longer in use (or in
`zeroize` 1.0, whichever comes first), the need to specify explicitly
that no `Drop` handler should be derived via `zeroize(no_drop)` can be
removed, however until then this change does the
safely-explicit-but-annoying thing by default so as to correct for
previous API mistakes.
0 commit comments