solana
solana copied to clipboard
solana-labs
curve25519-dalek zeroize dependency not compatible with other libraries
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:
- aws-types
- num-big-int-dig (which RSA relies on)
- jsonwebkey
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
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 openssl OS package.
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.
can confirm that i was able to implement RSA key generation and decryption using sfackler/rust-openssl without dependency issues.
Thanks for sharing this!
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)
Upgrading curve25519-dalek to version 4 will not solve the problem Because there is also ed25519-dalek-bip32 (v0.2.0), which depends on ed25519-dalek (v1.0.1), which also depends on curve25519-dalek (version = "3") There is an ed25519-dalek v2.0.0-rc.3 that uses curve25519-dalek "=4.0.0-rc.3", but there is no stable version yet, so ed25519-dalek-bip32 is still on ed25519-dalek 1.0.1 So the way out of this situation may be:
- Wait for the release of the stable version of ed25519-dalek -> and then update ed25519-dalek-bip32 -> and then update deps in solana core
- Replace the ed25519-dalek-bip32 crate - as far as I understand it is used only for generating a keypair using Bip32 Hierarchical Derivation
- Replace the ed25519-dalek-bip32 crate - as far as I understand it is used only for generating a keypair using Bip32 Hierarchical Derivation
solana also uses ed25519-dalek 1.01, so I don't think this is an option.
https://github.com/solana-labs/solana/blob/3dcb3827314517eeec6018cbe28e1ae535437f76/Cargo.toml#L182
- Replace the ed25519-dalek-bip32 crate - as far as I understand it is used only for generating a keypair using Bip32 Hierarchical Derivation
solana also uses ed25519-dalek 1.01, so I don't think this is an option.
https://github.com/solana-labs/solana/blob/3dcb3827314517eeec6018cbe28e1ae535437f76/Cargo.toml#L182
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). This is not stable and should only be used if it blocks development (for example, I need to use the async solana cli in my project, which is implemented in the latest versions of solana, so incompatibility with other packages is a big issue for me). The best option would be to wait until ed25519-dalek releases v2 and then 1) wait for ed25519-dalek-bip32 to update or 2) replace ed25519-dalek-bip32 (spl also needs to be updated)
There is another dependency that needs to be updated to eliminate the awkward zeroize <1.4 dependency problem: aes-gcm-siv needs to be updated to v0.11.1.
can someone post a public example project for reproduction? hbu @samuelvanderwaal @whymidnight @hlgltvnnk @jbuckmccready?
@mschneider https://github.com/jbuckmccready/solana_zeroize_dep_example
hey @mschneider, thank you for tackling this issue. Do you have any idea when this is going to be fixed?
Currently we can't support Solana because of this issue. In our case, the conflict occurs with the last version of sqlx (0.7.2 at this time).
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/
hey @mschneider, thank you for tackling this issue. Do you have any idea when this is going to be fixed? Currently we can't support Solana because of this issue. In our case, the conflict occurs with the last version of
sqlx(0.7.2 at this time).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 sqlx features because of the zeroize version. Bumping aes-gcm-siv would be appreciated!
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
treats those and if it’s going to remain available. If not, change
repository to "https://github.com/mina86/curve25519-dalek/".
The aes-gcm-siv patch should be unnecessary as soon as new solana crates release happens.
If anyone got subtle dep conflict:
aes-gcm-siv = { git = "https://github.com/RustCrypto/AEADs", rev = "555ae1d82d000f01899498f969e6dc1d0a4fe467" }
It is a blocker to import ethers-rs and solana-sdk in the same binary.
All workarounds above are fragile.
error: failed to select a version for `zeroize`.
... required by package `curve25519-dalek v3.2.1`
... which satisfies dependency `curve25519-dalek = "^3.2.1"` of package `solana-program v1.17.11`
... which satisfies dependency `solana-program = "=1.17.11"` of package `solana-sdk v1.17.11`
... which satisfies dependency `solana-sdk = "^1.17.11"` of package `solana v0.1.0 (~/myproject/solana)`
versions that meet the requirements `>=1, <1.4` are: 1.3.0, 1.2.0, 1.1.1, 1.1.0, 1.0.0
all possible versions conflict with previously selected packages.
previously selected package `zeroize v1.5.3`
... which satisfies dependency `zeroize = "^1.5"` of package `elliptic-curve v0.13.5`
... which satisfies dependency `elliptic-curve = "^0.13.5"` of package `ethers-core v2.0.11`
... which satisfies dependency `ethers-core = "^2.0.11"` of package `ethers v2.0.11`
... which satisfies dependency `ethers = "^2.0.11"` of package `ethereum v0.1.0 (~/myproject/ethereum)`
... which satisfies path dependency `ethereum` (locked to 0.1.0) of package `main v0.1.0 (~/myproject/main)`
failed to select a version for `zeroize` which could resolve this conflict
from my pov resolution of this issue is still blocked by a zeroize upgrade. if you have a patch that resolves the issues feel free to send a PR, but I can’t guarantee it’ll get merged quickly because there’s a couple of downstream projects that need to be upgraded as well. not gonna lie the way rust crypto 4 has been rolled out is very painful. the current workaround is to prevent conflicts by pinning the old version and only using packages compatible with it.
@mschneider I have done a similar upgrade before for hyperledger ursa.
@dougEfresh if you have any intermediate work on this, let me know, otherwise I'm opening a draft PR with the patches.
OK. So at present the patch uis using a Solana vendored curve25519-dalek that removed the explicit pin on zeroize. However, the upgrade to the curve25519-dalek of version 4.0.0 wasn't made, and I think I should just do it.
Not quite sure why my PR with this patch to this repo was autoclosed. I've raised another one into agave. LMK.
I'm still experiencing the same issue while using solana-client, solana-sdk and ethers-rs @mschneider
Cargo.toml
Error
