Closed bisgardo closed 2 years ago
Hi @bisgardo! Thanks for the recommendation, and we'd be happy to take a PR for this.
Note that I don't believe we ever settled on our MSRV, so that might also be something worth figuring out.
If you do pin zeroize
, I'd suggest using a fairly liberal version range. Something like:
">=1, <1.4"
@tarcieri Thanks for the suggestion. In the PR I propose ">=1, <1.5"
in order to not cause a downgrade from 1.4.1
which is the version that the library currently resolves to.
Hi! I tried everything 1.4 and above and @tarcieri is correct that that breaks our CI checking the MSRV of 1.41, so I've pinned it to that in f7381ac.
What’s the recommended course of action for folks like myself who depend on both curve25519-dalek
and other crates which depend on zeroize
1.4+?
Ideally curve25519-dalek
could bump MSRV to 1.51, at which point pinning around the zeroize
version could be removed
Could that happen on the 4.0-pre branch?
Could that happen on the 4.0-pre branch?
That would be much appreciated, currently the newest 4.0.0-pre.2 can't be used with the newest RustCrypto crates because of that.
See #386
The authors of the
zeroize
library explicitly state that changes to the minimum supported Rust version might result in a minor version bump only. This library only registers the dependency as version"1"
. This means that even when depending on this library through a specific version, it might result in the minimum supported Rust version being bumped behind your back.This happened recently with the release of
v1.4.0
and caused the issue described in https://github.com/Concordium/concordium-node/issues/109.I suggest that minor version bumps of dependencies are accompanied by minor version bumps in this library as well.
I would be happy to make the change to
Cargo.toml
if this is ok.