Add API test and fix up SecretKey API
#842
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The docs for rand::StepRng say "deprecated without replacement". In fact, according to rust-random/rand#1634 which removed them, the "replacements" are SmallRng, or Pcg*, or Xoshiro*. That is, the replacement is a separate crate. `rand` exposes Xoshiro256PlusPlus as "SmallRng", if you enable a feature that enables the extra dep. Unfortunately we cannot do this for tests only, because Cargo does not support optional dev-dependencies. (Ten year old issue: rust-lang/cargo#1596 .. last comment three years ago.) Directly use rand_xoshiro instead.
This test is full of FIXMEs because our existing APIs are not very consistent, but this should at least help check that things are not getting worse.
I'd like to pull the different key types into their own modules. It will be easier if we create a subdirector for them all. In the end we will re-export everything.
Move-only, except for a couple import paths.
Deprecate the from_byte_array method, which unfortunately we just added in 0.31.x. We may want to backport yet another deprecation.
|
cc @tcharding these PRs are actually right in your wheelhouse. |
You mean gut and re-write the whole crate with barely a worry in the world? Now you are talking my language - BOOM! |
tcharding
approved these changes
Sep 1, 2025
|
Mad, next secp release is going to be hot as f***. |
chain-forgexcr45
added a commit
to chain-forgexcr45/rust-secp256k1
that referenced
this pull request
Sep 28, 2025
…tKey` API
44dae89894f8e40069f717f5746206cb83703e06 key/secret: encapsulate SecretKey in module that enforces invariants (Andrew Poelstra)
41bb44294cb883740d938b16f0874424e095c018 key: add {from,to,as}_secret_bytes methods (Andrew Poelstra)
9b84072757d3916969d7c8ed6ba08e3e749044cc move SecretKey into its own module (Andrew Poelstra)
e86555ad3e2991cfa72a0fb7725b50b3a6c9f352 move key.rs to key/mod.rs (Andrew Poelstra)
0619163ea2df49f70e0d30e36186af8a2506ec18 tests: add API test (Andrew Poelstra)
4853f671312782e871baad9ae745278f0cc78cd6 test: remove deprecated StepRng (Andrew Poelstra)
Pull request description:
Now that we unconditionally have a global context object we can basically redo the whole API of this crate to avoid requiring these objects (although for the next release we should continue to support the old API, to make the transition easier).
We know a lot more about Rust and API design than we did when we put together the old one, so we can do this in a consistent and principled way. This isn't a huge crate. We should be able to do the "main" data structures (`SecretKey', `PublicKey`, `ecdsa::Signature`, `schnorr:Signature`, `Message`) in a week or so, then cut a new release which enables context-free keygen, verification and signing.
ACKs for top commit:
tcharding:
ACK 44dae89894f8e40069f717f5746206cb83703e06
Tree-SHA512: 60659532b7ac65c85ac0c7bf9b78d0f080d4b3f556a02623bcb2b737ab73d02bf493153f751b435c7be5041435900870868b4e18b321207d50aaceb96b2f56da
william2332-limf
added a commit
to william2332-limf/rust-secp256k1
that referenced
this pull request
Oct 2, 2025
…tKey` API
44dae89894f8e40069f717f5746206cb83703e06 key/secret: encapsulate SecretKey in module that enforces invariants (Andrew Poelstra)
41bb44294cb883740d938b16f0874424e095c018 key: add {from,to,as}_secret_bytes methods (Andrew Poelstra)
9b84072757d3916969d7c8ed6ba08e3e749044cc move SecretKey into its own module (Andrew Poelstra)
e86555ad3e2991cfa72a0fb7725b50b3a6c9f352 move key.rs to key/mod.rs (Andrew Poelstra)
0619163ea2df49f70e0d30e36186af8a2506ec18 tests: add API test (Andrew Poelstra)
4853f671312782e871baad9ae745278f0cc78cd6 test: remove deprecated StepRng (Andrew Poelstra)
Pull request description:
Now that we unconditionally have a global context object we can basically redo the whole API of this crate to avoid requiring these objects (although for the next release we should continue to support the old API, to make the transition easier).
We know a lot more about Rust and API design than we did when we put together the old one, so we can do this in a consistent and principled way. This isn't a huge crate. We should be able to do the "main" data structures (`SecretKey', `PublicKey`, `ecdsa::Signature`, `schnorr:Signature`, `Message`) in a week or so, then cut a new release which enables context-free keygen, verification and signing.
ACKs for top commit:
tcharding:
ACK 44dae89894f8e40069f717f5746206cb83703e06
Tree-SHA512: 60659532b7ac65c85ac0c7bf9b78d0f080d4b3f556a02623bcb2b737ab73d02bf493153f751b435c7be5041435900870868b4e18b321207d50aaceb96b2f56da
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Now that we unconditionally have a global context object we can basically redo the whole API of this crate to avoid requiring these objects (although for the next release we should continue to support the old API, to make the transition easier).
We know a lot more about Rust and API design than we did when we put together the old one, so we can do this in a consistent and principled way. This isn't a huge crate. We should be able to do the "main" data structures (
SecretKey',PublicKey,ecdsa::Signature,schnorr:Signature,Message`) in a week or so, then cut a new release which enables context-free keygen, verification and signing.