Comments (7)
While trying to see what can be done about this, I ran into a differently worded error:
291 | impl Zeroize for Box<[u8;3]> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `alloc::boxed::Box<[u8; 3]>`
|
= note: upstream crates may add a new impl of trait `core::marker::Copy` for type `alloc::boxed::Box<[u8; 3]>` in future versions
So apparently Box
could in the future implement Copy
, making this not a false positive, but I haven't been able to find an issue or link with more information.
This doesn't help solve the problem, but it surprised me enough to share.
from crates.
The Box
impls in zeroize
are gated on the alloc
feature in zeroize
.
Are you using secrecy
with --no-default-features
?
from crates.
Adding this to the tests in the zeroize
crate
fn impls_zeroize<Z: Zeroize>(_: &Z) {}
#[cfg(feature = "alloc")]
#[test]
fn zeroize_box() {
let mut boxed_arr = Box::new([42u8; 3]);
// works
<[u8; 3] as Zeroize>::zeroize(&mut *boxed_arr);
// works
boxed_arr.zeroize();
// doesn't work
<Box<[u8; 3]> as Zeroize>::zeroize(&mut boxed_arr);
// doesn't work
impls_zeroize(&boxed_arr);
assert_eq!(boxed_arr.as_ref(), &[0u8; 3]);
}
shows that Box
appears to implement Zeroize
due to deref coercion.
Adding
#[cfg(feature = "alloc")]
#[cfg_attr(docsrs, doc(cfg(feature = "alloc")))]
impl Zeroize for Box<[u8; 3]>
{
fn zeroize(&mut self) {
(**self).zeroize()
}
}
gets the test to compile, but adding
#[cfg(feature = "alloc")]
#[cfg_attr(docsrs, doc(cfg(feature = "alloc")))]
impl<Z> Zeroize for Box<Z>
where
Z: Zeroize,
{
fn zeroize(&mut self) {
(**self).zeroize()
}
}
fails with the error
Compiling zeroize v1.1.1 (/home/c/pjts/secretbox/src/vendor/zeroize)
error[E0119]: conflicting implementations of trait `Zeroize` for type `alloc::boxed::Box<_>`:
--> src/lib.rs:375:1
|
237 | / impl<Z> Zeroize for Z
238 | | where
239 | | Z: DefaultIsZeroes,
240 | | {
... |
244 | | }
245 | | }
| |_- first implementation here
...
375 | / impl<Z> Zeroize for Box<Z>
376 | | where
377 | | Z: Zeroize,
378 | | {
... |
385 | | }
386 | | }
| |_^ conflicting implementation for `alloc::boxed::Box<_>`
|
= note: downstream crates may implement trait `DefaultIsZeroes` for type `alloc::boxed::Box<_>`
Which is a false positive, DefaultIsZeroes
being a subtrait of Copy
.
from crates.
Thanks for reporting this and the writeup. It seems there are major issues with both zeroize
and secrecy
.
Per the conflicting implementations error you're getting, I'm not sure how to address the Box
situation in zeroize
without specialization. I'll try to take a look at both of these issues in depth when I have some more spare time.
from crates.
Isn't the problem that SecretBox<T>
should not be implemented as Secret<Box<T>>
but as a custom type instead? The reason is that we want T: Zeroize
not Box<T>: Zeroize
.
pub struct SecretBox<T: Zeroize>(Box<T>);
from crates.
@ia0 yes, I've wanted to refactor it to something like that, but haven't had time
from crates.
Cool! Thanks for the feedback and no worries. Nothing urgent, just wanted to check my understanding.
from crates.
Related Issues (20)
- bip32: why can't private ExtendedKey instances convert to `ExtendedPublicKeys` with `TryFrom`? HOT 2
- secrecy: how should one use `SecretBytesMut`? HOT 2
- Is it possible to get derived address from a private key generated by bip32 crate?
- Cannot clone a `SecretVec<u8>` as `u8` is not `CloneableSecret` HOT 1
- secrecy: Using the serde feature in a no-std environment
- secrecy: Add an example to deserialize a SecretString
- RUSTSEC-2021-0073: Conversion from `prost_types::Timestamp` to `SystemTime` can cause an overflow and panic
- zeroize 1.4.0 manifest problems HOT 3
- error: failed to download `zeroize v1.4.1` ... consider adding `cargo-features = ["resolver"]` to the manifest HOT 3
- zeroize attribute accepted on struct fields, to no effect HOT 2
- `hkd32::Error` does not implement `std::error::Error` HOT 1
- impl Default for Zeroizing (possibly guarded by DefaultIsZeroes) HOT 2
- bip32: Build breakage, possibly due to conflicting generic-array dependencies. HOT 2
- `#[zeroize(drop)]` no-op in zeroize_derive v1.1 for `enum`s HOT 2
- Please publish a patch release of zeroize_derive 1.1 that fixes #876 but keeps the MSRV constant HOT 2
- RUSTSEC-2020-0071: Potential segfault in the time crate
- Implement `Zeroize` for `NonZeroX` HOT 1
- zeroize: implement `Zeroize` for `PhantomData` HOT 3
- MSRV in bip32 README is incorrect HOT 1
- secrecy: Zeroize an serde_json::Value HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from crates.