Recently we found and fixed an unsoundness issue in the
`preallocated_gen_new` function. As we have yet to release 0.25.0 we can
just update the changelog to reflect the newly merged fix.
As is customary add a newline between rustdoc heading and content. Done
so that the code is identical to other released code (during backport
the space was added).
1e6eb6cb4d shut clippy up (Andrew Poelstra)
f961497e69 context: introduce unsafe `PreallocatedContext` trait (Andrew Poelstra)
Pull request description:
Stop this from being a generic function over all contexts, to only a function generic over contexts where we can bound the lifetime precisely. Introduces a new unsafe trait. I *believe* the only code this breaks was already unsound:
* code that tried to use one of the `*Preallocated` context markers with an incorrect lifetime
* code that tried to use `preallocated_gen_new` with a non-`*Preallocated` marker, which I believe we allowed before (I just noticed this now) and almost certainly would've led to UB on drop
Fixes#543
ACKs for top commit:
Kixunil:
ACK 1e6eb6cb4d
tcharding:
ACK 1e6eb6cb4d
Tree-SHA512: 44eb4637a2f86d5b16d40174cb9e27f37cf8eb4f29546159dbbdcd3326d01f9de2f500ba732376dd84e67ebc3528c709d2d4e2aceb8a329bcb9fb9d25c9b89cb
9b07e8e8c5 secp-sys: Use NonNull in API instead of *mut T (Tobin C. Harding)
Pull request description:
Currently we expect non-null pointers when we take `*mut T` parameters, however we do not check that the pointers are non-null because we never set VERIFY in our C build. We can use the `NonNull` type to enforce no-null-ness as long as we use `NonNull::new`. In a couple of instances we manually check that a buffer is not empty and therefore that the pointer to it is non-null so we can safely use `NonNull::new_unchecked`.
Replace mutable pointer parameters `*mut T` (e.g. `*mut c_void`) and return types with `NonNull<T>`.
Fix#546
### Note
The description above fully explains the issue to the best of my knowledge, if the description is not spot on then I'm not fully understanding the issue. Please correct me if this is the case.
> One unfortunate thing is that this means that we wouldn't be able to implement CPtr for secp256k1::Context, which is our designated "expose types from secp256k1-sys which is not stable" semver escape hatch.
You've lost me here? `secp256k1::Context` is a trait did you mean `secp256k1::Secp256k1` or `secp256k1_sys::Context`?
ACKs for top commit:
apoelstra:
ACK 9b07e8e8c5
Tree-SHA512: 37aceebfa62e590ce8cc282c35b014ad018e5cfbea99402ed3aa1fcbaa69e01a01c1c1f32351f5f15a7d270e31da5b239ee5bc11d2343cf866082ad85df6a622
Fixes unsoundness in `preallocated_gen_new` which previously did not
properly constrain the lifetime of the buffer used to back the context
object. We introduce an unsafe marker trait, and impl it for our
existing preallocated-context markers.
Annoyingly the trait has to be public even though it should never be
used directly, and is only used alongside the sealed `Context` trait,
so it is de-facto sealed itself.
Fixes#543
Currently we expect non-null pointers when we take `*mut T` parameters,
however we do not check that the pointers are non-null because we never
set VERIFY in our C build. We can use the `NonNull` type to enforce
no-null-ness as long as we use `NonNull::new`. In a couple of instances
we manually check that a buffer is not empty and therefore that the
pointer to it is non-null so we can safely use `NonNull::new_unchecked`.
Replace mutable pointer parameters `*mut T` (e.g. `*mut c_void`) and
return types with `NonNull<T>`.
Fix#546
082c3bdd1c Use NonNull for Secp256k1 inner context field (Tobin C. Harding)
Pull request description:
For raw pointers that can never be null Rust provides the `core::ptr::NonNull` type. Our `Secp256k1` type has an inner field that is a non-null pointer; use `NonNull` for it.
Fix: #534
ACKs for top commit:
apoelstra:
ACK 082c3bdd1c
Tree-SHA512: 80e6a931bc2efaaa5f9d11f7407b45960f6db669137fbb4f835dff3607b1459d6ea2bc039a649460c14008381a10d095e18df7e3b7b6b4c4b85a360e0127eef0
1dbd7691da secp256k1: Bump crate version to 0.25.0 (Tobin C. Harding)
Pull request description:
Add changelog notes and bump the crate version to v0.25.0!
ACKs for top commit:
apoelstra:
ACK 1dbd7691da
Tree-SHA512: 462f103842d093ca019dea26e3e1bc9faf10d711846afe74562340320cfbd030f121bf834963f347fdeab2f3477dc3c3e15e3653619c634c149cddc059a60042
For raw pointers that can never be null Rust provides the
`core::ptr::NonNull` type. Our `Secp256k1` type has an inner field that
is a non-null pointer; use `NonNull` for it.
Fix: #534
129ba3cd58 Remove size field (Tobin C. Harding)
Pull request description:
The `Secp256k1` `size` field is a cached value that we get using `ffi::secp256k1_context_preallocated_size` or
`ffi::secp256k1_context_preallocated_clone_size`, both of which just return the result of `sizeof(rustsecp256k1_v0_6_1_context)`. Instead of caching this value we can just call
`ffi::secp256k1_context_preallocated_clone_size` in the `Drop` implementation.
Fix#537
ACKs for top commit:
apoelstra:
ACK 129ba3cd58
Tree-SHA512: 3fce7863065e4b485fd2d1fdbbfe7002fa6188f1a703d89fdda570a1a32471d298e2e33fb8c5951a56a79facb5d2b427d58e473b5cb1d68eb02ffed728392b97
The `Secp256k1` `size` field is a cached value that we get using
`ffi::secp256k1_context_preallocated_size` or
`ffi::secp256k1_context_preallocated_clone_size`, both of which just
return the result of `sizeof(rustsecp256k1_v0_6_1_context)`. Instead of
caching this value we can just call
`ffi::secp256k1_context_preallocated_clone_size` in the `Drop`
implementation.
7d3dc354d7 secp256k1-sys: Remove unused flags in build.rs (Elichai Turkel)
Pull request description:
These are no longer used in upstream, so there's no reason for us to set them
ACKs for top commit:
apoelstra:
ACK 7d3dc354d7
Tree-SHA512: 79ecbed19ba9eb61640306bc5413b139e902ee84b7e122e8ae57e451f2b132371440554f21ed075ed34d9d702c4316e4b170ca638c774532ecf5a11456b4e2ad
ecdad39ef4 context: Improve rustdocs (Tobin C. Harding)
e945751d85 schnorr: Improve rustdocs (Tobin C. Harding)
47f19a78ef Use lowercase for schnorr (Tobin C. Harding)
27b3e92889 Do trivial cleanup to module level docs (Tobin C. Harding)
Pull request description:
Audit of docs in `rust-secp256k1` and do a few trivial fixes. The docs are in pretty good condition, they just need more content as described in #128 if that issue is still valid.
ACKs for top commit:
apoelstra:
ACK ecdad39ef4
Tree-SHA512: 7466090325e02331f11e34cd38625541fbe8e642882afa6ddf2cf5d11ed669c7b2b48fd5b819915392760f4c6ef4ee460c2e622b3af648f99906c3ac408045d4
513144c923 Remove serde_keypair module (Tobin C. Harding)
Pull request description:
Done while unsuccessfully trying to solve https://github.com/rust-bitcoin/rust-secp256k1/issues/514#
The `serde_keypair` module appears to be only used for testing, however it is part of the public API for the `key` module?
serde de/serialization is already implemented on `KeyPair` by way of the normal `serde` traits, there is no obvious reason for the `serde_keypair` and the `KeyPairWrapper`.
Remove the `KeyPairWrapper` and test `KeyPair` serde impls directly.
ACKs for top commit:
apoelstra:
ACK 513144c923
Tree-SHA512: 23891217f3afc7cb3bb03431946e9866ee6ae611153fca8d93fe393b5a4abbd41d4713c6aa5ab24eb2734d8c8d94a9f6aed47316284b4097aa40f49f055f36b6
6d747301e8 secp256k1: Document safety constraints (Tobin C. Harding)
85681cece7 secp256k1-sys: Document safety constraints (Tobin C. Harding)
Pull request description:
Functions that are `unsafe` should include a `# Safety` section.
- Patch 1: Documents `unsafe` methods in `secp256k1-sys`. Please not this includes a minor refactor.
- Patch 2: Documents the `unsafe` `Context` trait
Together these two patches remove `#![allow(clippy::missing_safety_doc)]` from the repo.
Fix: #447
## Note to reviewers
The only function that was curly to understand the safety of was `secp256k1_context_create`, all the other stuff should be trivial to review.
ACKs for top commit:
apoelstra:
ACK 6d747301e8
Tree-SHA512: 247216c3f9e655fe8c2854b71613b31b6241318e877e83a1e4873ce84e481975a832d05cd748577f437f88b166ff287a537d26c012568e7378caed458ec55867
The `serde_keypair` module appears to be only used for testing, however
it is part of the public API for the `key` module?
serde de/serialization is already implemented on `KeyPair` by way of the normal
`serde` traits, there is no obvious reason for the `serde_keypair`
and the `KeyPairWrapper`.
Remove the `KeyPairWrapper` and test `KeyPair` serde impls directly.
Functions that are `unsafe` should include a `# Safety` section. Because
we have wrapper functions to handle symbol renaming we essentially have
duplicate functions i.e., they require the same docs, instead of
duplicating the docs put the symbol renamed function below the
non-renamed function and add a docs linking to the non-renamed function.
Also add attribute to stop the linter warning about the missing safety
docs section.
Remove the clippy attribute for `missing_safety_doc`.
42bf99f11b Add full stop (Tobin C. Harding)
96f9fd3e56 Link to MESSAGE_SIZE in Error docs (Tobin C. Harding)
036bd0d011 secp256k1: Generalize docs on Error (Tobin C. Harding)
Pull request description:
The docs on `Error` currently mention ECDSA which is no longer correct since we use this error in `schnorr` as well.
Fix the `Error` doc issue described above and do a couple trivial other fixes while we are touching the code.
ACKs for top commit:
apoelstra:
ACK 42bf99f11b
Tree-SHA512: e1658d909c3588736570517a351e85c85c014ee31efe09fd262654dad873b0dcd3dbb6c8ad40866a24ee8e2e9bf0be99e5eb35251f6640222b953a0eb2a732ca
We can help readers of the HTML docs by using a link to the constant.
While we are at it shorten the doc comment so it fits on one line (in
under 100 chars).
c0ae3e7d35 fix formatting on master (Andrew Poelstra)
Pull request description:
Looks like I need to check formatting now before merging things :) master CI is broken because of cargo fmt.
ACKs for top commit:
tcharding:
ACK c0ae3e7d35
Tree-SHA512: 9dc22eb5edfb565309cfd14cb9634abba196e46591da8c21d241bd686df8436a8af371c6520ea6ae688fcf81a835919a1bc9a3730f206ba6ef758087efa282e1
b9eefea092 Add documentation on side channel attacks to SecretKey (Tobin C. Harding)
7cf3c6c8a4 Implement constant time comparison for SecretKey (Tobin C. Harding)
19039d9281 Remove `Ord`/`Hash` traits from SecretKey (Tobin C. Harding)
4a0c7fca6a Do not use impl_array_newtype for SecretKey (Tobin C. Harding)
Pull request description:
Add constant time comparison implementation to `SecretKey`.
This PR does as suggested [here](https://github.com/rust-bitcoin/rust-secp256k1/issues/471#issuecomment-1179783309) at the end of the issue discussion thread.
Fix: #471
ACKs for top commit:
apoelstra:
ACK b9eefea092
Tree-SHA512: 217ed101b967cc048954547bcc0b3ab09e5ccf7c58e5dcb488370caf3f5567871152505a3bfb4558e59eea4849addaf1f11e1881b6744b0c90c633fa0157a5ae
75f3886812 Add cargo fmt to pre-commit githook (Tobin C. Harding)
0516ddeb8d Add formatting check to CI (Tobin C. Harding)
c7807dff9c Run the formatter (Tobin C. Harding)
Pull request description:
We recently introduced `rustfmt` to the codebase but I forgot to turn it on in CI.
- Patch 1: Preparatory formatting fixes, introduced since we merged the [formatting PR](https://github.com/rust-bitcoin/rust-secp256k1/pull/499)
- Patch 2: Enable formatting in CI
- Patch 3: Add formatting to the pre-commit hook
ACKs for top commit:
apoelstra:
ACK 75f3886812
Tree-SHA512: 5ac4ab4015a9728ef890e0c4fe90afcb5e45ab7665da5a8ee289dc877c1ea5c6236e54b68b7122841597864b04606c8bfae7dec86c4b6be74d32437299057b5f
d5294a182a ci: Check rustdocs build (Tobin C. Harding)
Pull request description:
Currently we are not failing the docs build in CI if any warnings are generated.
Exit the script with error code 1 if docs build throws any warnings.
ACKs for top commit:
apoelstra:
ACK d5294a182a
Tree-SHA512: cf8a8feda8cbb4ea741b31cd0fa0e728724c60fb688f4fafcd132e93ec1a278093c64d34bfcc7e692cc80d0871b71656fc83b670a59b5f3b76c4b8fc3815d200
We recently added a constant time `eq` implementation however library
users can inadvertently bypass this protection if they use `AsRef`. To
help prevent this add documentation to the `SecretKey` and also to the
`AsRef` implementation.
The current trait implementations of `Ord` and `PartialOrd` for
`SecretKey` leak data when doing the comparison i.e., they are not
constant time. Since there is no real usecase for ordering secret keys
remove the trait implementations all together.
Remove `Hash` at the same time because it does not make sense to
implement it if `Ord`/`PartialOrd` are not implemented.
In preparation for changing the logic of comparison trait (Ord, Eq)
implementations on the `SecretKey` copy all the code out of
`impl_array_newtype` and implement it directly in `key.rs`.
Refactor only, no logic changes (although I removed a few unneeded
references).
Add code to the CI script, guarded on env var `DO_FMT` to run the
formatter.
Add a formatting job to the nightly CI job as a separate step, in a
similar fashion to how the other nightly steps are done.
Currently we are not running the formatter in CI, in preparation for
doing so run `cargo +nightly fmt` to clear all current formatting
issues.
No manual changes.
9850550734 Move AsRef impl block next to Index (Tobin C. Harding)
4d42e8e906 Derive Copy and Clone (Tobin C. Harding)
b38ae97eaf Implement stable comparison functionality (Tobin C. Harding)
630fc1fcb6 Remove len and is_empty from impl_array_newtype macros (Tobin C. Harding)
9788b6df88 Remove leading colons from impl_array_newtype methods (Tobin C. Harding)
2bb08c21e5 Remove as_[mut_]ptr from impl_array_newtype macros (Tobin C. Harding)
3e28070187 Duplicate impl_array_newtype (Tobin C. Harding)
635890322a Add newline to end of file (Tobin C. Harding)
Pull request description:
Supersedes #515
The primary aim of this PR is to fix the fact that we currently implement various comparison traits (`Ord`, `PartialEq`) by comparing the inner byte arrays. These bytes are meant to be opaque and are not guaranteed across versions of `libsecp256k1`.
This PR is a bit involved because I had to detangle all the various types (across both `secp256k1` and `secp256k1-sys`) that use the `impl_array_newtype` macro.
- Patch 1: is trivial cleanup
- Patch 2: Step one of the PR is duplicating the macro into both crates so we can tease them apart.
- Patch 3-5: Are cleanup of the now duplicated `impl_array_newtype` macros
- Patch 6: Is the meat and potatoes
- Patch 7,8: Further minor clean ups to the macro
I had a lot of fun with this PR, I hope you enjoy it too.
Fix: #463
ACKs for top commit:
apoelstra:
ACK 9850550734
Tree-SHA512: 160381e53972ff882ceb1d2d47bac56a7301a2d13bfe75d3f6ff658ab2c6fbe516ad856587c4d23f98524205918ca1a5f9b737e35c23c7a01b476c92d8d1792f
9c748550b4 Fix feature gating (Tobin C. Harding)
Pull request description:
Currently we have a few problems with our feature gating, attempt to audit all feature gating and fix it by doing:
1. Do not enable features on optional dependencies (`rand` and `bitcoin-hashes`) in dev-dependencies, doing so hides broken feature gating in unit tests.
2. Do not use unnecessary feature combinations when one feature enables another e.g. `any(feature = "std", feature = "alloc")`.
3. Enable "std" from "rand-std" and "bitcoin-std" (and fix features gating as for point 2).
4. Clean up code around `rand::thread_rng`, this is part of this patch because `thread_rng` requires the "rand-std" feature.
5. Clean up CI test script to test each feature individually now that "rand-std" and "bitcoin-hashes-std" enable "std".
ACKs for top commit:
apoelstra:
ACK 9c748550b4
Kixunil:
ACK 9c748550b4
Tree-SHA512: 3f8e464eeab1fe279249b5097082774c3de076ec9537162f367013098bde45957b12067a7434389e520bfacd3b415274f897917bf000f332d52cf960b1d4aecf
There is no obvious reason why not to derive `Copy` and `Clone` for
types that use the `impl_newtype_macro`. Derives are less surprising so
deriving makes the code marginally easier to read.
Currently we rely on the inner bytes with types that are passed across
the FFI boundry when implementing comparison functions (e.g. `Ord`,
`PartialEq`), this is incorrect because the bytes are opaque, meaning
the byte layout is not guaranteed across versions of `libsecp26k1`.
Implement stable comparison functionality by doing:
- Implement `core::cmp` traits by first coercing the data into a stable
form e.g., by serializing it.
- Add fast comparison methods to `secp256k1-sys` types that wrap types
from libsecp, add similar methods to types in `secp256k1` that wrap
`secp256k1-sys` types (just call through to inner type).
- In `secp256k1-sys` feature gate the new `core::cmp` impls on
`not(fuzzing)`, when fuzzing just derive the impls instead.
Any additional methods added to `secp256k1-sys` types are private,
justified by the fact the -sys is meant to be just a thin wrapper around
libsecp256k1, we don't want to commit to supporting additional API
functions.
Please note, the solution presented in this patch is already present for
`secp256k1::PublicKey`, this PR removes that code in favour of deriving
traits that then call down to the same logic in `secp256k1-sys`.
Currently we have a few problems with our feature gating, attempt to
audit all feature gating and fix it by doing:
1. Do not enable features on optional dependencies (`rand` and
`bitcoin-hashes`) in dev-dependencies, doing so hides broken feature
gating in unit tests.
2. Do not use unnecessary feature combinations when one feature enables
another e.g. `any(feature = "std", feature = "alloc")`.
3. Enable "std" from "rand-std" and "bitcoin-std" (and fix features
gating as for point 2).
4. Clean up code around `rand::thread_rng`, this is part of this patch
because `thread_rng` requires the "rand-std" feature.
5. Clean up CI test script to test each feature individually now that
"rand-std" and "bitcoin-hashes-std" enable "std".
Tobin C. Harding
Andrew Poelstra
Elichai Turkel