-
Notifications
You must be signed in to change notification settings - Fork 957
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
feat(identity): implement protobuf encoding for all key types #3681
Conversation
Unreleased patch version 0.43.1 bumped. Added entry for PR 3606: Deriving 'Clone' for 'mdns::Event'
New unreleased minor version 0.44.0.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Unsynced co-authered change.
…s to disabled feature
libp2p-identity
keypairs
Now I don't expect the branch to be merged with such aggressive changes...... |
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.
Thank you for the tidy-up!
There are some good ideas in here. I've made some comments throughout. Most importantly, I think we can easily do this in a non-breaking way by just adding new functions and deprecating old ones.
I merged latest master because there was some diff of other PRs. |
I've resolved the merge conflicts on this one for you. Are you still planning on splitting multiple PRs out of this one? Probably the easiest is to:
That way, we can slowly chip away at the changes in this PR and land them in master piece-wise! |
This pull request has merge conflicts. Could you please resolve them @drHuangMHT? 🙏 |
Now I guess this commit is mostly about renaming. |
This pull request has merge conflicts. Could you please resolve them @drHuangMHT? 🙏 |
/// Encode a private key as protobuf structure. | ||
/// | ||
/// See <https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md#key-types> for details on the encoding. | ||
pub fn encode_protobuf(&self) -> Result<Vec<u8>, DecodingError> { |
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.
It is a shame that we rename the function here and cannot do the signature change to infalliblity at the same time. For that we need to also implement RSA encoding but I think for that we need to switch to the rsa
crate which I want to debate first.
I wonder:
- should we delay the rename of this function until then so we can land the rest now
- should we rename it with the others and send users through another rename (+ signature change) once we support RSA
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.
Delay the rename then.
Should we remove this from |
Thanks, I removed the milestone. |
Are we |
Has anything changed around the situation of the |
Well the crate has been audited RustCrypto/RSA#60, but the non constant-time issue RustCrypto/RSA#19 is still not solved yet. |
In that case, I'd say we keep things as is for now. I have very limited capacity this month and will step down from active maintenance after that so I'd like to focus the remaining time on other issues. |
Not planned in the foreseeable future, closing this to clean up work tree on my fork. |
Description
Previously, we only supported encoding the ed25519 private key. To be fully compliant with the spec, we also need to support encoding the other 3 key types ECDSA, RSA and secp256k1.
Resolves #3630.
Related #3623.
Related #3350.
Related #3649.
Notes & open questions
Breaking change.
Should we make the code panic when encountering missing feature?Blocked by #540.
Change checklist