zeroize: Allow versions newer than 1.3 for curve25519-dalek (solana…

…-labs#33516)

`curve25519-dalek` v3.2.1 has a constraint on the maximum `zeroize`
version to be no more than 1.3.

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 `curve25519-dalek`
restriction is overly pessimistic.  These packages lifted this
restriction in newer versions, but we still depend on older version and
can not immediately update.

Cargo.toml

@@ -431,3 +431,76 @@ ntapi = { git = "https://github.com/solana-labs/ntapi", rev = "97ede981a1777883f
 # overrides in sync.
 solana-program = { path = "sdk/program" }
 solana-zk-token-sdk = { path = "zk-token-sdk" }
+#
+# === zeroize versioning issues ===
+#
+# A number of packages used explicit upper bound on the `zeroize` package, such
+# as `>=1, <1.4`.  The problem is that cargo still does not duplicate `zeroize`
+# if a newer version is available and requested by another package and just
+# fails the whole dependency resolution process.
+#
+# This is described in
+#
+# https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-requirements
+#
+# So we have to patch `zeroize` dependency specifications in the projects that
+# introduce these constraints.  They have already removed these constraints in
+# newer versions, but we have not updated yet.  As we update, we need to remove
+# these patch requests.
+#
+# When our dependencies are upgraded, we can remove this patches.  Before that
+# we might need to maintain these patches in sync with our full dependency
+# tree.
+
+# Our dependency tree has `aes-gcm-siv` v0.10.3 and the `zeroize` restriction
+# was removed in the next commit just after the release.  So it seems safe to
+# patch to this commit.
+#
+# `aes-gcm-siv` v0.10.3 release:
+#
+# https://github.com/RustCrypto/AEADs/releases/tag/aes-gcm-siv-v0.10.3
+#
+# Corresponds to commit
+#
+# https://github.com/RustCrypto/AEADs/commit/6f16f4577a1fc839a2346cf8c5531c85a44bf5c0
+#
+# Comparison with `6105d7a5591aefa646a95d12b5e8d3f55a9214ef` pinned here:
+#
+# https://github.com/RustCrypto/AEADs/compare/aes-gcm-siv-v0.10.3..6105d7a5591aefa646a95d12b5e8d3f55a9214ef
+#
+[patch.crates-io.aes-gcm-siv]
+git = "https://github.com/RustCrypto/AEADs"
+rev = "6105d7a5591aefa646a95d12b5e8d3f55a9214ef"
+
+# Our dependency tree has `curve25519-dalek` v3.2.1.  They have removed the
+# constrain in the next major release.  Commit that removes `zeroize` constrain
+# was added to multiple release branches.  Bot not to the 3.2 branch.
+#
+# `curve25519-dalek` maintainers are saying they do not want to invest any more
+# time in the 3.2 release:
+#
+# https://github.com/dalek-cryptography/curve25519-dalek/issues/452#issuecomment-1749809428
+#
+# So we have to fork and create our own release, based on v3.2.1.  Commit that
+# removed `zeroize` constrain on the `main` branch cherry picked on top of the
+# v3.2.1 release.
+#
+# `curve25519-dalek` v3.2.1 release:
+#
+# https://github.com/dalek-cryptography/curve25519-dalek/releases/tag/3.2.1
+#
+# Corresponds to commit
+#
+# https://github.com/dalek-cryptography/curve25519-dalek/commit/29e5c29b0e5c6821e4586af58b0d0891dd2ec639
+#
+# Comparison with `c14774464c4d38de553c6ef2f48a10982c1b4801`:
+#
+# https://github.com/dalek-cryptography/curve25519-dalek/compare/3.2.1...solana-labs:curve25519-dalek:c14774464c4d38de553c6ef2f48a10982c1b4801
+#
+# Or, using the branch name instead of the hash:
+#
+# https://github.com/dalek-cryptography/curve25519-dalek/compare/3.2.1...solana-labs:curve25519-dalek:3.2.1-unpin-zeroize
+#
+[patch.crates-io.curve25519-dalek]
+git = "https://github.com/solana-labs/curve25519-dalek.git"
+rev = "c14774464c4d38de553c6ef2f48a10982c1b4801"