We use the `AlignedType` and take a pointer to its inner data, never
access the data directly - this confuses clippy causing a "field is
never used" warning.
Shoosh the lint and add a code comment explaining why.
In preparation for doing a point release add a changelog entry, bump the
version, and update all the `0_9_0` identifiers in the vendored code.
Done so we can release the wasm-build bug fix.
This patch adds a declaration of the `ecdsa_parse_compact` function to
util.h. This function isn't called from within libsecp proper; it is
called in lax_der_parse.c (which we patch separately with a declaration)
and in example code (which we don't compile at all).
Prepare for release by doing:
- Add changelog entry to `secp256k1-sys` for the recent version bump ready
for release.
- Bump the version of secp256k1 to 0.28.0
- Add changelog entry to `secp256k1` for the imminent release.
Create bindings for all methods and static types in ellswift.h in
secp256k1-sys and their respective safe-rust types.
All methods are extensively commented and tested using BIP324's
test vectors
We use "keypair" in identifiers (local vars and function names) but
`KeyPair` - one of them is wrong.
Elect to follow upstream and define keypair as a single word i.e., use
`Keypair` for type name and `keypair` in identifiers.
This patch can be reproduced mechanically by doing two
search-and-replace operations on all files excluding the CHANGELOG
- Replace "KeyPair" with "Keypair"
- Replace "key_pair" with "keypair"
We no longer need to manually configure the docsrs build to highlight
feature guards since we use the `doc_auto_cfg` feature. Somehow when we
added usage of that feature we forgot to remove the other attributes.
Improve the secp256k1 readme by:
- Use a top level markdown header (level 1)
- Add a link to the SECG's website (www.secg.org)
- Add a link for `secp256k1` to bitcoin.it explaining the curve
Improve the secp256k1-sys readme by:
- Mirror secp256k1 readme badges, heading, docs link
- Basic cleanup
- Use 100 column width
- Use backticks
- Use capitals
896e6c7f2d Introduce SPDX license identifiers (Tobin C. Harding)
Pull request description:
Licenses are boring as hell, so is are all the comments at the top of each file. This patch makes no comment on the merit of license comments in each file, rather this patch reduces the license comment to the minimum possible with no loss of meaning - an SPDX license identifier.
Note also please that we remove the "written by" comments as well for the following reasons (discussed recently on rust-bitcoin repo):
- they are not descriptive because many devs contributed
- they have a tendency to include the wrong date because of cut'n'pasta
- all this info is in the git history
ref: https://spdx.dev/ids/#how
cc elichai because this PR removes your name but you were not explicitly part of the conversation on `rust-bitcoin` about this topic. Here is the issue: https://github.com/rust-bitcoin/rust-bitcoin/issues/1816 also for more on SPDX see https://github.com/rust-bitcoin/rust-bitcoin/pull/1076
ACKs for top commit:
Kixunil:
ACK 896e6c7f2d
apoelstra:
ACK 896e6c7f2d
Tree-SHA512: 6f0ff7ec2632aed510df362e2fb9cf25fe02cae347bdd4a481804a3ea2b9e060c4ec2c85de3e9d1d40920e4b9c4eecfab127e61f3d076886fe8f2fb4bff9f5a7
Licenses are boring as hell, so is are all the comments at the top of
each file. This patch makes no comment on the merit of license comments
in each file, rather this patch reduces the license comment to the
minimum possible with no loss of meaning - an SPDX license identifier.
Note also please that we remove the "written by" comments as well for
the following reasons (discussed recently on rust-bitcoin repo):
- they are not descriptive because many devs contributed
- they have a tendency to include the wrong date because of cut'n'pasta
- all this info is in the git history
ref: https://spdx.dev/ids/#how
2ae7ca9cf2 secp-sys: update README for new vendoring script (Andrew Poelstra)
4b02e9c405 run new vendor-libsecp.sh; fix upstream CHANGELOG. (Andrew Poelstra)
b58a60fd6c rewrite ./vendor-libsecp.sh (Andrew Poelstra)
Pull request description:
For Nix purposes I need the revendoring script to work without network access and without user interaction. I also realized it would be convenient if the script could figure out what the right version prefix is supposed to be. Then I noticed some shellcheck issues.
Anyway I just rewrote the whole thing. I'm now able to run this script within nix and vet that the current contents of the `depend/` directory are consistent with the secp256k1-HEAD-revision.txt, for all commits.
ACKs for top commit:
tcharding:
ACK 2ae7ca9cf2
sanket1729:
reACK 2ae7ca9cf2
Tree-SHA512: ea3028e3517b2dbe0f34bcf20685945ecf543fc42e01f10d435432ad290088586b2a2b0f0e94bc3ce59ec38727656eb04eef57c5df6a34da77070e0f288b1d84
Note: Only effects code when fuzzing is enabled, as such does not
include a mention in the changelog.
Now that we have Rust 1.48 as the MSRV we no longer need the custom
implementations of `PartialEq`, `Eq`, `PartialOrd`, `Ord`, and `Hash`.
We can just let users of the `impl_array_newtype` macro derive these
traits if they want them.
Remove the custom implementations and add derives to our two users of
the macro.
We are upgrading the MSRV across the whole Rust Bitcoin ecosystem.
Update the README, clippy config file, and CI to use the new MSRV.
Changes to use the new MSRV will be done later.
Add mention of MSRV to `secp256k1-sys`, add unreleased section to both
changelogs.
This rewrite:
* Fixes some shellcheck issues (bad quoting, use of | instead of ||
near the beginning of the file)
* Automatically computes the version prefix, depend directory, etc.,
and provides instructions to override this with env vars if the
user really wants to do this.
* Detects when it would be destructive and refuses to run unless
passed the -f flag, rather than prompting the user for a yes/no
* Adds the capability to use cp rather than git clone, which I need
to run this from within Nix.
* Whitelists CHANGELOG.md which shouldn't get substituted.
We are ready to release a new minor version of `secp256k1-sys`, in order
to do so we must make change the symbol names to reflect the new version
as well as the usual changelog and version bump.
In preparation for releasing `secp256k1-sys` v0.8.1 do:
- Rename symbols to from `0_8_0` -> `0_8_1`, done mechanically (search
and replace)
- Add changes log notes (includes changelog entry for 0.8.0)
- Bump `secp256k1-sys` crate version 0.8.0 -> 0.8.1, justified because
we have added a new public function.
This PR implements a `non_secure_erase()` method on SecretKey,
KeyPair, SharedSecret, Scalar, and DisplaySecret. The purpose
of this method is to (attempt to) overwrite secret data with
valid default values. This method can be used by libraries
to implement Zeroize on structs containing secret values.
`non_secure_erase()` attempts to avoid being optimized away or
reordered using the same mechanism as the zeroize crate: first,
using `std::ptr::write_volatile` (which will not be optimized
away) to overwrite the memory, then using a memory fence to
prevent subtle issues due to load or store reordering.
Note, however, that this method is *very unlikely* to do anything
useful on its own. Effective use involves carefully placing these
values inside non-Copy structs and pinning those structs in place.
See the [`zeroize`](https://docs.rs/zeroize) documentation for tips
and tricks, and for further discussion.
[this commit includes a squashed-in commit from tcharding to fix docs
and helpful suggestions from apoelstra and Kixunil]
`libsecp256k1` v0.2.0 was just released.
Update the vendored code using
`./vendor-libsecp.sh depend 0_8_0 21ffe4b`
```
git show 21ffe4b
commit 21ffe4b22a9683cf24ae0763359e401d1284cc7a (tag: v0.2.0)
Merge: 8c949f5 e025ccd
Author: Pieter Wuille <pieter@wuille.net>
Date: Mon Dec 12 17:00:52 2022 -0500
Merge bitcoin-core/secp256k1#1055: Prepare initial release
e025ccdf7473702a76bb13d763dc096548ffefba release: prepare for initial release 0.2.0 (Jonas Nick)
6d1784a2e2c1c5a8d89ffb08a7f76fa15e84fff5 build: add missing files to EXTRA_DIST (Jonas Nick)
13bf1b6b324f2ed1c1fb4c8d17a4febd3556839e changelog: make order of change types match keepachangelog.com (Jonas Nick)
b1f992a552785395d2e60b10862626fd11f66f84 doc: improve release process (Jonas Nick)
ad39e2dc417f85c1577a6a6a9c519f5c60453def build: change package version to 0.1.0-dev (Jonas Nick)
90618e9263ebc2a0d73d487d6d94fd3af96b973c doc: move CHANGELOG from doc/ to root directory (Jonas Nick)
Pull request description:
Based on #964
ACKs for top commit:
sipa:
ACK e025ccdf7473702a76bb13d763dc096548ffefba
Tree-SHA512: b9ab71d7362537d383a32b5e321ef44069f00e3e92340375bcd662267bc5a60c2bad60222998e6602cfac24ad65efb23d772eac37c86065036b90ef090b54c49
```
Requires a new version of `secp256k1-sys`, use v0.8.0
- Update the `secp256k1-sys` manifest (including links field)
- Update symbols to use 0_8_0
- Add a changelog entry
- depend on the new version in `secp256k1`
Which in turn requires a new version of `secp256k1`, use v0.26.0
We are ready to release a new minor version of `secp256k1-sys`, in order
to do so we must make change the symbol names to reflect the new version
as well as the usual changelog and version bump.
In preparation for releasing `secp256k1-sys` v0.7.0 do:
- Rename symbols to from `0_6_1` -> `0_7_0`, done mechanically (search
and replace)
- Add changes log notes
- Bump `secp256k1-sys` crate version 0.6.1 -> 0.7.0, justified because
we have added new public methods to various types (e.g.,
`PublicKey::cmp_fast_unstable`)
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
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
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`.
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`.
An array in Rust has no concept of length, it is a fixed size data type.
Equally an array cannot be "empty", again since it is a fixed size data
type. These are methods/concepts seen in slices and vectors.
Remove the `len` and `is_empty` methods.
92b733386f Support non-WASM platforms that are missing `string.h` (Matt Corallo)
Pull request description:
Dunno why we haven't seen this elsewhere, but when trying to build locally for an ARM embedded target `secp256k1-sys` failed to compile as it was missing `string.h`, just like WASM.
This patch adds a trivial fallback - if we fail to compile initially we unconditionally retry with the wasm-sysroot, giving us a valid `string.h`.
ACKs for top commit:
tcharding:
ACK 92b733386f
apoelstra:
ACK 92b733386f
Tree-SHA512: 81cbc5023f349681a3bef138506d9314be948b8b7b78bb2b2ffacf43b0c97d92ea67238105009a94b05a0a3adbd4113ed68f79a0a303708d95c6a7f520d5170e
68c73850d8 Minimise FFI in the public API (Tobin C. Harding)
Pull request description:
Normal users should never need to directly interact with the FFI layer.
Audit and reduce the use of `ffi` types in the public API of various types. Leave only the implementation of `CPtr`, and document this clearly as not required by normal users. Done for:
- PublicKey
- XOnlyPublicKey
- KeyPair
- ecdsa::Signature
- ecdsa::RecoverableSignature
ACKs for top commit:
apoelstra:
ACK 68c73850d8
Tree-SHA512: 8242527837872f9aba2aab19b02c2280ca1eb1dfd33c8ca619726d981811d72de3e5a57cbde2fbe621eb8e50e43f488804cd51d27949459da1c0ceb03fca35e3
Normal users should never need to directly interact with the FFI layer.
Audit and reduce the use of `ffi` types in the public API of various
types. Leave only the implementation of `CPtr`, and document this
clearly as not required by normal users. Done for:
- PublicKey
- XOnlyPublicKey
- KeyPair
- ecdsa::Signature
- ecdsa::RecoverableSignature
Tobin C. Harding
Andrew Poelstra
Davidson Souza
kwantam
Tibo-lg
Elichai Turkel