-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
curve25519-dalek zeroize dependency not compatible with other libraries #26688
Comments
I'm currently running into the same issue with dependencies being incompatible with the outdated zeroize on curve25519-dalek. |
this was blocking for me when i tried using RustCrypto/RSA however, at least for rsa, i found sfackler/rust-openssl that binds to this seems to be a viable alternative in the meantime. |
can confirm that i was able to implement RSA key generation and decryption using sfackler/rust-openssl without dependency issues. |
Thanks for sharing this! |
Any update on this ? Majority of packages already bumped |
curve25519-dalek 3.2.1 seems to be a blocker here, a 4.0.0 release is imminent (rc.2 was published on March 26) |
4.0.0 is released |
Upgrading curve25519-dalek to version 4 will not solve the problem
|
solana also uses ed25519-dalek 1.01, so I don't think this is an option. Line 182 in 3dcb382
|
This is a temporary workaround (if you want solana to be compatible with other crates that use zeroize) to use the raw version of ed25519-dalek (Im using "2.0.0-rc.3" in my fork) and then replace the ed25519-dalek-bip32 (because I don't want to fork it as well). |
ed25519-dalek v2.0.0 is released! |
There is another dependency that needs to be updated to eliminate the awkward |
can someone post a public example project for reproduction? hbu @samuelvanderwaal @whymidnight @hlgltvnnk @jbuckmccready? |
hey @mschneider, thank you for tackling this issue. Do you have any idea when this is going to be fixed? You can find a demo of the issue here (which is basically the same as the two above): https://github.com/klefevre/solana_zeroize_dep_example/ |
Here's a branch with a fix for just solana-program https://github.com/dbcfd/solana/tree/fix/deps. Still have to work through the other parts of solana. |
I am also unable to use several |
In the meanwhile, here’s a workaround: [patch.crates-io]
# aes-gcm-siv 0.10.3 and curve25519-dalek 3.x pin zeroize to <1.4
# which conflicts with other dependencies requiring zeroize ^1.5.
# We’re patching both crates to unpin zeroize.
#
# For aes-gcm-siv we’re using the same revision Solana uses in
# an (as of now) unreleased commit, see
# https://github.com/solana-labs/solana/commit/01f1bf27994d9813fadfcd134befd3a449aaa0bd
#
# For curve25519-dalek we’re using commit from a PR, see
# https://github.com/dalek-cryptography/curve25519-dalek/pull/606
aes-gcm-siv = { git = "https://github.com/RustCrypto/AEADs", rev = "6105d7a5591aefa646a95d12b5e8d3f55a9214ef" }
curve25519-dalek = { git = "https://github.com/dalek-cryptography/curve25519-dalek", rev = "8274d5cbb6fc3f38cdc742b4798173895cd2a290" } The second entry points at a commit in a PR. I’m not sure how GitHub The aes-gcm-siv patch should be unnecessary as soon as new solana |
@mina86 Works for me, thank you. |
If anyone got subtle dep conflict:
|
It is a blocker to import ethers-rs and All workarounds above are fragile.
|
@mschneider |
What's the recommended solution now? This is a pretty big pain point for us. |
It depends on what exactly the conflict is for you. You might be able to replace the external crypto lib with something that doesn't use |
Our dependency conflict is with ethers-rs which will be very difficult to fix as it is deep in the stack. How do we patch it? The suggestion above doesn’t work. |
@AraMambreyan I presume https://github.com/alloy-rs/alloy is not working either? |
Migrating to Alloy will be a huge effort for a repository as large as ours. I doubt it will work anyway as I’d expect it to use newer versions of the dependencies than ethers-rs. |
I would suggest vendoring your own versions of the dependencies instead. I was supposed to fix this, but had to move to other projects. We could pool efforts on that. You should have my contact details, so we can discuss |
Meanwhile, here's a stack which we use in our internal projects:
Which should work with
|
Oh, hey Alex, good to see you here, small world! Will ping you. |
Note: there's an upstream fix being worked on here: anza-xyz#1693 |
That's a good start. |
I used the patches from solana Cargo.toml and it worked for compiling my project with both Solana and libp2p |
FYI, all versions of It would be very good for Solana to prioritize PRs like anza-xyz#1693 as currently it's using unmaintained versions of important crypto libraries. |
Sure, I meant my comment as a workaround for those who just want to get started with the dependencies and can’t compile, rather than ignoring any security concerns (personally, this would have helped me a few weeks ago when I was starting my project). I’ve been patiently waiting for that PR to be merged too |
@uandere Hey, did you managed to solve this issue? |
This PR was open in Jul 20, 2022. Still not fixed. I guess Solana owners don't want us to use their library. |
It's being worked on here and looks very close: anza-xyz#1693. |
More dependency issues anza-xyz#612 I'm also facing them. |
this works for me: |
Try adding Tauri 2.0.0-beta with features rustls , that should fail 😢 |
i am also facing this with incompatible zeroize versions |
|
Note: this PR to upgrade It's unclear when it will make it into a release, but it should address the issue. |
This solved my issued |
@danimhr, How to fix it? |
How can i use the solana-sdk in my project?
|
you can try
and check how we build downstream projects: https://github.com/anza-xyz/agave/blob/f9f8b60ca15fa721c6cdd816c99dfd4e9123fd77/scripts/build-downstream-anchor-projects.sh#L72 So maybe something like that helps
|
This issue looks to be resolved with the release of Solana v2.1.0 crates (at least for the most part). However, the new release has also introduced a new set of compatibility issues with existing crates that still use older versions of |
Problem
Solana v1.8.x relied on curve25519-dalek ^v2.1.0 which itself has a zeroize dependency of ^1.
However, Solana v1.9+ rely on curve25519-dalek ^v3.2.1 which limits zeroize to a range of >=1, <1.4 which is not compatible with many other cryptography libraries (or libraries which depend on cryptography libraries) which use ^1.4 or ^1.5. E.g.s:
It's unclear why curve25519-dalek hasn't bumped yet but there is an open PR to do so. Most other cryptography libraries seem to have bumped to v1.4+
Are there any known workarounds for this? If curve25519-dalek doesn't bump, is it possible for Solana to drop back down to ^v2.1?
Proposed Solution
The text was updated successfully, but these errors were encountered: