-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Uses aptos-core x25519-dalek library with relaxed zeroize dep #9354
Conversation
22b7d23
to
b102673
Compare
It looks like we will slowly be forking every dalek library due to their poor maintenance. We also had to fork We should discuss a workflow / process for keeping these forks up to date, no? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, with one reservation. Originally with the forked repo I patched zeroize, then force overwrote main in the fork with the patch to get the additional write protections the main branch has (so that main in the fork is now the latest stable release of x25519-dalek with the zeroize update). My intuition is that using main in the fork instead of a branch would be safer for this reason.
b102673
to
47392da
Compare
@mstraka100 merging to unblock; I was unable to force push the other version to main |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
✅ Forge suite
|
cc @gregnazario who recently had some issues with our |
This is a little problematic, every patch that we apply, requires uses of the Rust SDK to have to also apply the patch |
Description
So there’s this fun thing in rust-landia where the cryptographic library we use - dalek-cryptography/x25519-dalek#92 - where they’ve pinned a version of their zeroize dependency to a
minor version, and have refused to backport relaxing that constraint for almost a year now. Instead they’ve been focused on their V2, which is in alpha. Other libraries have moved on from relying (at this
point) on the very old version of zeroize , and more and more often you see zeroize > 1.4 . This creates a fun incompatibility!
A few of us have run into this now, trying to use libraries from aptos core in other services. This creates an interesting situation: either we have to use an alpha (pre-release- currently on rc3) version of a
core cryptography library (which sounds very sketch), or we have to use much older versions of other dependencies (if any such exist). It’s affected indexer (twice now, in different services), and IC: it’s safe
to assume any rust users in our ecosystem would also run into the same issues.
Test Plan
Existing build + tests