Breaking change curve25519-dalek

[bgallois]

The PR (dalek-cryptography/curve25519-dalek#619) introduced a breaking change from version 4.1.1 to 4.1.2, with the 4.1.2 version only compatible with the latest nightly.

The unpinned version

ed25519-zebra/Cargo.toml

Line 21 in c39bd43

curve25519-dalek = { version = ">= 4.0, < 4.2", default-features = false, features = ["alloc", "digest", "zeroize", "precomputed-tables"] }

is causing issues for downstream projects using older nightly versions. It would be beneficial to enforce a specific version to prevent this problem in the future, even if breaking changes are introduced only incrementing the maintenance release number.

[conradoplg]

I'm not sure. By this argument we should pin a specific version of all dependencies, which would also cause breakages for people who rely on different versions of them. Also I don't see the point in supporting old nightly compilers.

Isn't it possible to pin the curve25519-dalek to 4.1.1 in your project?

[bgallois]

Sorry, but I poorly formulated the problem. I was thinking of not actually pinning the dependency, but rather replacing version = ">= 4.0, < 4.2" with version = "4.1.2" (or the latest version of the dependency at release time). However, since the breaking change occurs with a patch version increment, it will still be the same issue, but it allows for more flexibility in automatic downstream upgrades and avoid being stuck with a certain version.

In fact, it is not possible because we rely on one repository that depends on ed25519-zebra (5 more that depend on curve25519-dalek ), which are now incompatible with old nightlies. Additionally, the same repository has another dependency with a version that is not compatible with the latest nightly, so we are stuck until all the dependencies release a patch and hope that all the dependencies have some latitude in range of versions, so the updates can propagate.

It's not really an issue, so I'll close it, but it's more to draw your attention to this dependency that doesn't have the same constraints as the others.

[conradoplg]

Got it, thanks for reporting it. We were also hit by this issue in one of our projects ☹️