Please release (3.2.2?) with relaxed zeroize dependency

[soleinik-figment]

Please release with this commit at the top of main (relax zeroize dependency)

Reason

would resolve dependency issues across solana-program, cosmrs and subxt (so far, maybe more)

[tarcieri]

See #405 for the release tracking issue

[juchiast]

Can we just release 3.2.2 instead of waiting for 4.0.0?

[tarcieri]

The release of 4.0.0 is imminent

[juchiast]

@tarcieri Do you have a specific time?

[tarcieri]

Should hopefully be this week

[tarcieri]

It's out: https://crates.io/crates/curve25519-dalek/4.0.0

[ilya-bobyr]

We can not upgrade to 4.0.0 immediately as curve25519-dalek is an indirect dependency via ed25519-dalek version 1.0.1.
And we can not immediately upgrade from ed25519-dalek 1.0.1 to 2.0.0-rc as it is not a backward compatible change. We use some of the types provided by ed25519-dalek in our public API.

It would be really great if the zerioze constrain removal would not be coupled with the whole library upgrade.

I have a private fork of curve25519-dalek 3.2.1 that we have to use: 3.2.1...ilya-bobyr:curve25519-dalek:3.2.1-unpin-zeroize [1].

Would it make sense to send a PR that cherry picks one of these commits on top of 3.2.1 with the releases/3.2 branch?

• "Relax version constraints for zeroize dependency." 841b3a6 (x25519-2.0.0 / curve25519-4.0.0)
• "Relaxed zeroize dependency" 90292dc (x25519-2.0.0 / 4.0.0-pre.3)
• "Relax zeroize dependency and bump MSRV (Relax zeroize dependency #412)" 51572da (x25519-2.0.0 / 4.0.0-pre.3)

---

[1]: We do not care about the MSRV upgrade.
I just did not want to write a new commit and cherry picked #412 from the main branch.

[tarcieri]

ed25519-dalek 1.x is unmaintained, obsolete, and contains an unfixable security vulnerability because it requires breaking changes to fix.

Please upgrade to ed25519-dalek 2.x.

[ilya-bobyr]

Please upgrade to ed25519-dalek 2.x.

We absolutely should.
But we are providing a platform that a lot of people use.
Due to the major version upgrade, and due to the fact that we put some of the types directly into our API, we can not upgrade that easily.

When we do upgrade (and attempts has been already made), we would want to keep backward compatibility at the API level for some time.
Meaning, we would need to build with both ed25519-dalek 1.x and ed25519-dalek 2.x in our dependency graph.
And the zeroize constraint would still be there.

ed25519-dalek 1.x is unmaintained, obsolete, and contains an unfixable security vulnerability because it requires breaking changes to fix.

I can understand that you do not want to invest time into something that broken and is known to be obsolete.
But it would greatly help us to move forward if the zeroize constrain would be removed.

While we can build with a patched version of curve25519-dalek it is non-ideal if every user of our library would need to add the [patch] section into their Cargo.toml.