Releasing v4.0.0?

[kevinlewi]

Hello! Just wondering if there is a timeline or any blockers for upgrading the pre-release (v4.0.0-pre.1 currently) to v4.0.0. The opaque-ke library (https://github.com/novifinancial/opaque-ke) is also currently on a pre-release, depending on v4.0.0-pre.1 of this library, and I am waiting on this dependency to upgrade to a full release before doing the same with opaque-ke.

Thanks!

[gitmalong]

bump

[tarcieri]

See open issues here: https://github.com/dalek-cryptography/curve25519-dalek/issues?q=is%3Aissue+is%3Aopen+label%3Ado-for-4.0

• Several broken links in backend/internal documentation #341
• Remove dependencies #392
• Batch double-and-compress (on ristretto255) fails on the identity point #398
• Misleading description for hash-to-Edwards point #400
• Simplifying backend selection #414
• simd_backend: replace packed_simd_2 with std::simd #415
• Run rustfmt #416
• SemVer policy for pre-1.0 dependencies #442
• Add basepoint-tables crate feature #489
• Consistency regarding from_bytes APIs #491

[tarcieri]

Another issue it'd probably be good to address before a v4.0 release: https://github.com/dalek-cryptography/curve25519-dalek/pull/394/files

[pinkforest]

Fixing all the broken links and moving to docs.rs hosting #439 fixing #341

[tarcieri]

It looks like all of the issues in the list I made are fixed, however I opened one more: #442

[tarcieri]

#449 would be good to address as well

[pinkforest]

The two issues have been addressed -

SemVer policy was modified:

• Updates to README #453

Also re: #449 I'm trying to sneak this PR in:

• Fixes curve25519_dalek_bits defaults for cross and wasm #465

To document the backend selection stuff:

• Document curve25519_dalek_ backend and bits selection #467

#449 is otherwise sorted as the cfg(curve25519_dalek_bits = "32"|"64") was added in:

• Add target u32/u64 backend overrides #454

Also would love to see this PR in - just got to sort out one of the tests:

- #463 nm: my confusion - closed

Also some dependencies were made optional:

• Make rand_core optional #447
• Make digest optional #446

And @tarcieri got rid of std

• Remove std feature #459

[tarcieri]

The entire checklist is checked off. Seems like aside from e.g. documentation polish there are no remaining blockers for a final release?

[pinkforest]

I just need to fix the build.rs for wasm and cross-targets - doing that now - EDIT DONE:

• Fixes curve25519_dalek_bits defaults for cross and wasm #465

Also the backend selection documentation is here now ready:

• Document curve25519_dalek_ backend and bits selection #467

[SergeStrashko]

Releasing?

[tarcieri]

#489 is another change that would be nice to get in before a breaking release. I went ahead and added it to the list, and tagged it do-for-4.0

[nox]

Seems like #489 has been handled and all that remains is #491.

[tarcieri]

I closed #491. I don't think there are any remaining release blockers.

[jplatte]

Is there anything the community can help with to make the release happen?

[tarcieri]

#380 looks like it might be worth addressing

[jplatte]

Would it be possible to release curve25519-dalek 3.2.2 or 3.3.0 that is exactly the same as 3.2.1 but that allows zeroize versions >=1.4? It is a growing pain to find a working dependency resolution setup with many crates now requiring a zeroize version >=1.4 and curve25519-dalek still forcing zeroize 1.x to <1.4.

[rozbb]

@jplatte we have some prereleases on the 4.0 track already. If you use 4.0.0-rc.2 everything should Just Work.

[jplatte]

That unfortunately doesn't help because we also depend on x25519-dalek whose latest pre-release depends on curve25519-dalek 3.x (and ed25519-dalek but that seems to have an up-to-date pre-release).

[rozbb]

Ah apologies. We'll be cutting a new x25519 release this week. Sorry for the delays

[rozbb]

@jplatte x25519-dalek rc.2 is out

[tarcieri]

As far as I can tell all of the issues/PRs for proposed breaking changes are now closed: #521

I think #523 would be good to land first before a release, ideally getting another prerelease to make sure it doesn't break anything. I've dealt with miscompilation issues in the past with runtime feature autodetection + SIMD code so it'd be really nice to have some confidence that's not going to happen.

If we can land that and get another release candidate out, I think we're otherwise finally ready to release.

cc @rozbb @koute

[koute]

I've dealt with miscompilation issues in the past with runtime feature autodetection + SIMD code so it'd be really nice to have some confidence that's not going to happen.

FWIW FYI for the SIMD autodetection I replaced our use of curve25519-dalek in substrate + polkadot and synced our chain from scratch, both using the AVX2 and the AVX512 backends, and it correctly synced everything. So at the very least it shouldn't be horribly broken.

[daira]

It looks like this crate has been stuck on 4.0.0-rc.2 since March. That's unusually long for an rc period. A release would help us (zcashd) to eliminate old versions of digest and rand-core as dependencies.

[tarcieri]

#523 is the main blocker, and it's ready to merge

[rozbb]

Agreed. Sorry, end of semester and beginning of summer internship has been a lot. I think we can cut a new release this week, and maybe the other dalek crates at the same time (there's just 1 outstanding PR in ed- I think that upgrades to the new scalar API)

[tarcieri]

I reopened #414 to discuss the new feature-gating changes in #523, in hopes we can again simplify that back to something like what it had before, as I feel things have gotten problematically complex again with no clear use cases for that additional complexity

[hrxi]

It seems #414 is closed again. Does this mean a release could happen?

[pinkforest]

ed25519-dalek will need another rc I think but curve25519-dalek doesn't seem to have anything pending.

Pending issue re: ExpandedSecretKey (hazmat) for ed25519-dalek 2.0

• Make the to_bytes/from_bytes round trip of ExpandedSecretKey idempotent #541
• ed25519-dalek: make ExpandedSecretKey fields private #544
• ed25519-dalek: remove ExpandedSecretKey::to_bytes #545

On 24th consensus seemed two weeks would do for testing - so it could be next week for curve unless ed/x/curve sync release.

[AaronFeickert]

Any thoughts on #546? I opened it just a few hours after the last comment.

[jrose-signal]

I see there are still questions about ed25519-dalek, but anything holding up a release of x25519-dalek in the meantime? We use x+curve but not ed.

[pinkforest]

ICYMI The stable releases are out including curve25519-dalek 4.0.0 + ed/x25519-dalek 2.0.0 🥳

[jplatte]

Why is this issue still open then? ^^