-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
zeroize: Allow versions newer than 1.3 for aes-gcm-siv
#33618
zeroize: Allow versions newer than 1.3 for aes-gcm-siv
#33618
Conversation
`aes-gcm-siv` v0.10.3 has a constraints on maximum `zeroize` version, set to be 1.3 or below. At the same time, `cargo` does not want to construct a dependency graph with duplicate instances of a crate, when the first non-zero version of those instances are the same. That is, it refuses to build a workspace with both 1.3 and 1.4 versions of `zeroize`. `zeroize` is actually backward compatible, and `aes-gcm-siv` restriction is overly pessimistic. This package lifted this restriction in a newer versions, but we still depend on older versions and can not immediately update. In order to be able to use a version of `zeroize` newer than 1.3 we need to remove a similar restriction from `curve25519-dalek` as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Although I'm not sure the vibe on vendoring in the monorepo....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me also! It doesn't seem like it'll be possible to upstream the change
…#33618) `aes-gcm-siv` v0.10.3 has a constraints on maximum `zeroize` version, set to be 1.3 or below. At the same time, `cargo` does not want to construct a dependency graph with duplicate instances of a crate, when the first non-zero version of those instances are the same. That is, it refuses to build a workspace with both 1.3 and 1.4 versions of `zeroize`. `zeroize` is actually backward compatible, and `aes-gcm-siv` restriction is overly pessimistic. This package lifted this restriction in a newer versions, but we still depend on older versions and can not immediately update. In order to be able to use a version of `zeroize` newer than 1.3 we need to remove a similar restriction from `curve25519-dalek` as well.
…#33618) `aes-gcm-siv` v0.10.3 has a constraints on maximum `zeroize` version, set to be 1.3 or below. At the same time, `cargo` does not want to construct a dependency graph with duplicate instances of a crate, when the first non-zero version of those instances are the same. That is, it refuses to build a workspace with both 1.3 and 1.4 versions of `zeroize`. `zeroize` is actually backward compatible, and `aes-gcm-siv` restriction is overly pessimistic. This package lifted this restriction in a newer versions, but we still depend on older versions and can not immediately update. In order to be able to use a version of `zeroize` newer than 1.3 we need to remove a similar restriction from `curve25519-dalek` as well.
aes-gcm-siv
v0.10.3 has a constraints on maximumzeroize
version, set to be 1.3 or below.At the same time,
cargo
does not want to construct a dependency graph with duplicate instances of a crate, when the first non-zero version of those instances are the same. That is, it refuses to build a workspace with both 1.3 and 1.4 versions ofzeroize
.zeroize
is actually backward compatible, andaes-gcm-siv
restriction is overly pessimistic. This package lifted this restriction in a newer version, but we still depend on older versions and can not immediately update.In order to be able to use a version of
zeroize
newer than 1.3 we need to remove a similar restriction fromcurve25519-dalek
as well.