Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zeroize: Allow versions newer than 1.3 for curve25519-dalek #33516

Merged
merged 1 commit into from
Oct 23, 2023
Merged

zeroize: Allow versions newer than 1.3 for curve25519-dalek #33516

merged 1 commit into from
Oct 23, 2023

Conversation

ilya-bobyr
Copy link
Contributor

@ilya-bobyr ilya-bobyr commented Oct 4, 2023

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
Copy link

codecov bot commented Oct 4, 2023

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     

@ilya-bobyr ilya-bobyr marked this pull request as ready for review October 4, 2023 16:00
@wei1769
Copy link

wei1769 commented Oct 4, 2023

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
gregcusack previously approved these changes Oct 4, 2023
Copy link
Contributor

@gregcusack gregcusack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ilya-bobyr
Copy link
Contributor Author

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
Copy link
Contributor

t-nelson commented Oct 9, 2023

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

@ilya-bobyr ilya-bobyr changed the title zeroize: Allow versions newer than 1.3 zeroize: Allow versions newer than 1.3 for curve25519-dalek Oct 10, 2023
@gregcusack gregcusack self-requested a review October 13, 2023 16:41
gregcusack
gregcusack previously approved these changes Oct 13, 2023
Copy link
Contributor

@gregcusack gregcusack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
joncinque previously approved these changes Oct 13, 2023
Copy link
Contributor

@joncinque joncinque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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

`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 packages lifted this
restriction in newer versions, but we still depend on older version and
can not immediately update.
@ilya-bobyr ilya-bobyr dismissed stale reviews from joncinque and gregcusack via 1357582 October 21, 2023 01:35
@ilya-bobyr
Copy link
Contributor Author

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.

Copy link
Contributor

@joncinque joncinque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

Copy link
Contributor

@gregcusack gregcusack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm. thank you!

@ilya-bobyr ilya-bobyr merged commit a099c7a into solana-labs:master Oct 23, 2023
43 checks passed
@ilya-bobyr ilya-bobyr deleted the pr/remove-zeroize-1.3-hard-limit branch October 23, 2023 19:20
yihau pushed a commit that referenced this pull request Oct 31, 2023
…33930)

Fixes

    commit a099c7a
    Author: Illia Bobyr <[email protected]>
    Date:   Mon Oct 23 12:19:59 2023 -0700

    zeroize: Allow versions newer than 1.3 for `curve25519-dalek` (#33516)

Use correct commit hash from `solana-labs/curve25519-dalek.git`.
Yiwen-Gao pushed a commit to nitro-svm/solana that referenced this pull request Dec 5, 2023
…-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.
Yiwen-Gao pushed a commit to nitro-svm/solana that referenced this pull request Dec 5, 2023
…olana-labs#33930)

Fixes

    commit a099c7a
    Author: Illia Bobyr <[email protected]>
    Date:   Mon Oct 23 12:19:59 2023 -0700

    zeroize: Allow versions newer than 1.3 for `curve25519-dalek` (solana-labs#33516)

Use correct commit hash from `solana-labs/curve25519-dalek.git`.
Yiwen-Gao pushed a commit to nitro-svm/solana that referenced this pull request Dec 12, 2023
…-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.
Yiwen-Gao pushed a commit to nitro-svm/solana that referenced this pull request Dec 12, 2023
…olana-labs#33930)

Fixes

    commit a099c7a
    Author: Illia Bobyr <[email protected]>
    Date:   Mon Oct 23 12:19:59 2023 -0700

    zeroize: Allow versions newer than 1.3 for `curve25519-dalek` (solana-labs#33516)

Use correct commit hash from `solana-labs/curve25519-dalek.git`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants