zeroize: Allow versions newer than 1.3 for curve25519-dalek

[ilya-bobyr]

Problem

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. This package lifted this restriction in newer versions, but we still depend on older version and can not immediately update.

Summary of Changes

Use a patched version based on v3.2.1 that also removes the unnecessary constraint.

[codecov]

Codecov Report

Merging #33516 (1357582) into master (01f1bf2) will decrease coverage by 0.1%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #33516     +/-   ##
=========================================
- Coverage    81.8%    81.8%   -0.1%     
=========================================
  Files         806      806             
  Lines      217428   217428             
=========================================
- Hits       178058   178047     -11     
- Misses      39370    39381     +11     

[wei1769]

Thanks ser, you save me.
I'm thinking to upgrade ed25519-dalek and patch all breaking changes. That's a lot of work @@
This patch is clever

[gregcusack]

This is great! super helpful. avoids a ton of headaches! Thank you!

[ilya-bobyr]

Thanks ser, you save me. I'm thinking to upgrade ed25519-dalek and patch all breaking change. That's a lot of work @@ The patch is clever

People were already looking at it: #32836
The problem is that we use types provided by ed25519-dalek in the public API.
And if we update ed25519-dalek to a new major version, those types become incompatible.
It is a tricky problem to solve, unfortunately.

[t-nelson]

was there an attempt to work with upstream in either of these cases before vendoring? vendoring should really be a last resort

if we have to take this route, ideally put the vendored crates in in separate PRs to make the revert simple

[ilya-bobyr]

was there an attempt to work with upstream in either of these cases before vendoring?
vendoring should really be a last resort

Here is a thread with dalek-cryptography/curve25519-dalek:

dalek-cryptography/curve25519-dalek#452 (comment)

They do not seem to be interested in doing another release.
They are just saying we should upgrade.
I think, we would need curve25519-dalek with the zeroize constraint removed even if we upgrade, if we want to preserve backward compatibility in our public API.

if we have to take this route, ideally put the vendored crates in in separate PRs to make the revert simple

I'll split aes-gcm-siv and curve25519-dalek changes into two PRs.

[ilya-bobyr]

Split eas-gcm-siv changes into #33618.
I'll reuse this PR for the curve25519-dalek changes.
For now, it includes both, as two separate commits, as the second relies on the first.

[gregcusack]

LGTM. But ya with what trent said, I'm not sure how people feel about vendoring. This definitely solves a big headache with versioning though.....

[joncinque]

This looks good to me. It doesn't seem like it'll be possible upstream the change, and we'll likely need to keep dalek v1 in our public API for a long time to come, so we likely want this change when we include both dalek v2 and v1. I would get @t-nelson's approval too since he had reservations.

[t-nelson]

seems fine since upstream doesn't want to play ball.

This looks good to me. It doesn't seem like it'll be possible upstream the change, and we'll likely need to keep dalek v1 in our public API for a long time to come, so we likely want this change when we include both dalek v2 and v1. I would get @t-nelson's approval too since he had reservations.

given that we're going to try to take monorepo to 2.0 in 1.19, i'm hoping we'll never need to formally support v2 and our api can instead be purely based on traits that can be implemented externally

[ilya-bobyr]

Moved the fork to https://github.com/solana-labs/curve25519-dalek and rebased on top of the merged #33618.
This is now good for inclusion to fully remove the zerioze constraint.

[joncinque]

Looks great!

[gregcusack]

lgtm. thank you!