-
Notifications
You must be signed in to change notification settings - Fork 81
keypair / signature / ed25519: Deprecate dalek types from public API #107
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
Conversation
pub fn new_ed25519_instruction_with_signature( | ||
message: &[u8], | ||
signature: &[u8; SIGNATURE_SERIALIZED_SIZE], | ||
pubkey: &[u8; PUBKEY_SERIALIZED_SIZE], |
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.
These changes make a lot of sense.
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.
ok great! I tried to follow other verification method signatures like https://docs.rs/ed25519-dalek/latest/ed25519_dalek/fn.verify_batch.html, which go message, then signature, then verifying key
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.
Looks great! I left a couple of tiny queries.
Problem
The keypair, signature, and ed25519-program crates all expose
ed25519_dalek
types in their public APIs, either as inputs or outputs.This makes it difficult to land PRs like #26, since we'll just end up causing breaking changes.
Summary of changes
Rather than constantly break APIs whenever the ed25519_dalek crates publishes a new major version, deprecate all functions that use ed25519_dalek types and add non-dalek versions.
As part of this work, I copied over the Signature error from RustCrypto to use as a generic error. That way, we can choose when to make breaking changes, independent of dependency bumps. I wasn't able to do the same thing since we're not ready to start using
core::error::Error
everywhere.cc @kevinheavey