3b8a82eb2b Add changelog entry for removal of ONE_KEY (Tobin C. Harding)
Pull request description:
In the 0.25.0 release we removed the `ONE_KEY` const but did not mention it in the release notes. This makes upgrade harder than it should be.
In hindsight we should have deprecated the const then removed it.
Add a changelog entry to the 0.25.0 release mentioning the removal and the work around.
ACKs for top commit:
apoelstra:
ACK 3b8a82eb2b
Tree-SHA512: 0bbf47a2f0e5221719b3d04a895c8f784623e31fd149911cf1b92afa2487037ee9619cedc94ea1d22bffd540ef5aa94a56e98daa56751c94274c973825ec9d5d
d60b891126 Add a verify function to PublicKey (Tobin C. Harding)
Pull request description:
Expose signature verification functionality for schnorr signatures on the `XOnlyPublicKey` type.
Idea from Kixunil: https://github.com/rust-bitcoin/rust-bitcoin/pull/1744#issuecomment-1534200841
ACKs for top commit:
apoelstra:
ACK d60b891126
Tree-SHA512: 2ffa3de528b857c5b0a402815b71b35da913c668bea53b63801705fa6a86eb6d44766aa2395c02f67a4712b451c77caf627af9450183ae70957abf246a63c279
In the 0.25.0 release we removed the `ONE_KEY` const but did not mention
it in the release notes. This makes upgrade harder than it should be.
In hindsight we should have deprecated the const then removed it.
Add a changelog entry to the 0.25.0 release mentioning the removal and
the work around.
47aa740c74 Improve the README files (Tobin C. Harding)
Pull request description:
Improve the README files
Improve the secp256k1 readme by:
- ~Use a top level markdown header (level 1)~ Use HTML for header and badges
- 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:
- Use HTML for header and badges (a subset of the badges used in `rust-secp256k1` readme)
- Basic cleanup
- Use 100 column width
- Use backticks
- Use capitals
ACKs for top commit:
apoelstra:
ACK 47aa740c74
Tree-SHA512: 8f818ffcda93424430abd72da68d86215c2313479449775e9851aff854d3691180aadfe5052338c2695d85c6cac32e764c4f789301867407eef64d8c3990ef10
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
8af2cf12da add .serialize() function to schnorr signature (isaac-asdf)
Pull request description:
convert from Signature to a byte_array
ACKs for top commit:
Kixunil:
ACK 8af2cf12da
tcharding:
ACK 8af2cf12da
apoelstra:
ACK 8af2cf12da
Tree-SHA512: b69d58646cdba4d83a79189f18628590970f471771feef0e11e089d73bd934777e3554a448b88a3643203522fde98084fd7570a5cec400516166583a3433c000
7467b23a8d rustfmt: Use now config option fn_params_layout (Tobin C. Harding)
Pull request description:
`rustfmt` warns:
Warning: the `fn_args_layout` option is deprecated. Use
`fn_params_layout`. instead
As suggested, use now config option `fn_params_layout`.
ACKs for top commit:
apoelstra:
ACK 7467b23a8d
Tree-SHA512: c786607200f550839300234d72e387e76e648b51ccebb96d8fc7a3b607b1702e8410dca486930cf71321f7e0a0546ad55f589da58395c8b3e86d783b40f776a7
`rustfmt` warns:
Warning: the `fn_args_layout` option is deprecated. Use
`fn_params_layout`. instead
As suggested, use now config option `fn_params_layout`.
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
b6d0c3bfcd Use doc_auto_cfg (Tobin C. Harding)
Pull request description:
We can build docs using feature markers by using `doc_auto_cfg` now, no need to manually call the `doc` attribute.
ACKs for top commit:
Kixunil:
ACK b6d0c3bfcd
apoelstra:
ACK b6d0c3bfcd
Tree-SHA512: ab95968dcb664543d6e1ab5f00866fda1ac2862b86793bda0e19cdc354fbf22471c46a044ceabe8cba2d2fc32671604219fdcb5e96107e14096d20d2aceab0f3
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
f6c68ec329 Clarify the documentation of `normalize_s` (Matt Corallo)
Pull request description:
I was reading the docs for `normalize_s` and got confused what the point was - it says that libsecp "will only accept" signatures that are normalized, which led me to believe it would refuse to deserialize such signatures. This is untrue, it only refuses to *validate* such signatures.
ACKs for top commit:
apoelstra:
ACK f6c68ec329
Tree-SHA512: 27ac2f8819638fb889d0fbfb4bc1c07059854b8a15bf2dc2c4140eaf805eb15665fe3d87cadefd56c7b6200ef39818e8d6602e87d7ae7c1d4a4229d4829ea3d0
77808b7d83 WIP: Add toolchain matrix to job (Tobin C. Harding)
Pull request description:
Recently I changed CI to use the dtolnay runner and in doing so introduced a regression (knowingly) whereby we only ran the WASM tests with the stable toolchain.
Run the WASM tests with multiple toolchains
- stable
- beta
- 1.48.0
- nightly
ACKs for top commit:
apoelstra:
ACK 77808b7d83
Tree-SHA512: c55fc31977082ad8332a7ae05267ca464294227a6542c251ea9ae367b6935e41a3ae27e8505c88ba69a85eca4a8600d46fed189be5033f7a7b85093038cf8590
I was reading the docs for `normalize_s` and got confused what the
point was - it says that libsecp "will only accept" signatures that
are normalized, which led me to believe it would refuse to
deserialize such signatures. This is untrue, it only refuses to
*validate* such signatures.
3c1b576f47 ci: Rework github actions script (Tobin C. Harding)
d41bcc81d3 ci: Use dtonlnay runner for WASM (Tobin C. Harding)
Pull request description:
Rework the github actions script in line with `rust-bitcoin`, notably:
- Only run WASM test using stable toolchain (is this ok? cargo-cult-programmed from rust-bitcoin)
- Use dtonlay runner
- Split jobs up by toolchain
- Add Arch32bit job
- Add Cross test job
- Run linter as part of the test script
- Test docs build using stable toolchain and nightly toolchain
ACKs for top commit:
apoelstra:
ACK 3c1b576f47
Tree-SHA512: 9b7ec90fc0815de9433231a74af3993fa64f0308623f73bf3fcd1be34e48785088f4de19825fa86d140bb658eacfd606d124556fc389fbcd7fa37c0cafb8fd0a
Rework the github actions script in line with `rust-bitcoin`, notably:
- Use dtonlay runner
- Split jobs up by toolchain
- Add Arch32bit job
- Add Cross test job
- Run linter as part of the test script
- Test docs build using stable toolchain and nightly toolchain
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
7bba2bc3b5 secp256k1-sys: Remove custom implementations of Eq, Ord and friends (Tobin C. Harding)
a815272bfc secp256k1: Remove custom implementations of Eq, Ord and friends (Tobin C. Harding)
ee83c3a4f9 Bump MSRV to 1.48 (Tobin C. Harding)
0e2579fb96 Fix release date in changelogs (Tobin C. Harding)
Pull request description:
As per ecosystem wide change, bump the MSRV of both crates to 1.48
Patch 1 is a typo fix to the changelog, I don't see changelogs cached on crates.io in any way so this fix should be able to quietly go in.
Note before this is applied there is no mention of the MSRV in secp256k1-sys, was that intentional? If not, with this applied, we have a mention in the readme.
CI needs some more fixes (wasm job) but because patching CI often leads to me doing 300 pushes I'm leaving it to a separate PR.
ACKs for top commit:
apoelstra:
ACK 7bba2bc3b5
Tree-SHA512: 4e575c7e4f7d4a36e024eee407f8a757ad35be7225d8b8de71d57248c40801b05aeb12abf27ea9ce63215561527c8edb4d1807b09388b9d1dcdb52f453cd0981
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.
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.
bd9d3c9de7 test: pin 'half' dependency on 1.41.1. (Andrew Poelstra)
7fc84191ee cargo fmt (Andrew Poelstra)
1b12cc5f58 contrib: commit "minimal" and "latest" tested lockfiles (Andrew Poelstra)
0494f50b1a fix correct minimal versions for serde crates (Andrew Poelstra)
b03602bfaa tests: replace cbor with more-recently-deprecated serde_cbor (Andrew Poelstra)
Pull request description:
This is a proposed strategy for maintaining tested lockfiles in the rust-bitcoin ecosystem. The idea is that we would have both a "minimal" and a "latest" lockfile, and in both cases we have trusted crev reviews for all dependencies (this is not implemented here, I'd like to start by committing the lockfiles so we can agree what to review).
Periodically we can update the "latest" one to reflect new versions of deps that we've gotten around to reviewing.
I have local nix build scripts that are able to test every commit of proposed PRs against both lockfiles. In CI it is probably reasonable to at least do `cargo test --locked --all-features` with both of them, to make sure that the tests at least pass on each PR with them.
Thoughts?
ACKs for top commit:
sanket1729:
ACK bd9d3c9de7. Verified the lockfiles. The latest one has a couple lines diff, but that is expected :) . minimal one is the same
Tree-SHA512: 6f14406a595aa6a6006b35828080b00b1b87209cb3dd6512c0e08eb92ae1ff27df005494189504cd5654eac1607cc98e902ccdd62b221cb865652c29dd958463
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.
866cf8c732 Fix rustdoc link (Thomas DuBuisson)
Pull request description:
Not familiar with rustdoc, let's see what CI says to make sure I got it right.
ACKs for top commit:
apoelstra:
ACK 866cf8c732
Tree-SHA512: 47aaf5932d1622be071a189f15f93cc206e6aae53ee771a14bf18b6a0acecf057f15b69c3d2460b39d15ff2bb3f34984a544574de0bd279bbcaef04eb2077c42
6e0ae2a7bb Document sig verify's intentional limitation (Thomas M. DuBuisson)
Pull request description:
This bit of documentation is similar to the secp256k1 C lib comment:
```
* To avoid accepting malleable signatures, only ECDSA signatures in lower-S
* form are accepted.
```
ACKs for top commit:
apoelstra:
ACK 6e0ae2a7bb
Tree-SHA512: 3259898c497b33cb967eac910ce746d6ccf2706adb0563ce862737156ef82e65d486d1b83c62dd474350a1fce4a2f9f5da20509ed85af2c138f4ea3a29cc240c
This is only needed for the serde test, so don't bother putting it in
the README. Downstream users won't encounter this dependency and don't
need to care about it.
The `cbor` crate has been unmaintained for several years, and depends on
the ancient `rustc_serialize` crate which (a) doesn't build on WASM, and
(b) doesn't build when we use a minimal-dep Cargo.lock. (The latter is
because cbor specifies rustc_serialize 0.3.0 when it should specify 0.3.1,
but there is nothing we can do to fix that when cbor is unmaintained.)
This changes a hardcoded value in a regression test, but it's because
we're replacing the serialization engine rather than changing our code,
so this is not actually a change.
5ae136d7bd Bump secp256k1-sys version to 0.8.1 (Tobin C. Harding)
Pull request description:
We just bumped the version of `secp256k1`, since we recently added a new public function to `secp256k1-sys` we need to bump the minor version number there too.
Should have been done as part of #588, its hard to get good help :)
ACKs for top commit:
apoelstra:
ACK 5ae136d7bd
Tree-SHA512: e763257ede269544f4fd21fd76cf4279dff2dcb4835933652a796b0ad54f364f9a893c13c85b5d05acd6805bc51d98b639fa9c1330fad5fa2313d28aafc2bb60
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.
45395190c2 Bump version to 0.27.0 (Tobin C. Harding)
8e772493dc Depend on bitcoin_hashes v0.12 (Tobin C. Harding)
Pull request description:
Depend on the newly released `bitcoin_hashes` version 0.12, add changelog, and bump to v0.27.0
ACKs for top commit:
Kixunil:
ACK 45395190c2
apoelstra:
ACK 45395190c2
Tree-SHA512: 9ea99c88a90d0d34dfbbd3e467ea77a2981a7eae75c52163eed805381683e7555ea841d9c953787ab878ce8848d26fd9a593bb2eb52b5be28cee3930a373434c
8fffbeab13 implement "non_secure_erase" methods (kwantam)
Pull request description:
This PR adds [`Zeroize`](https://docs.rs/zeroize) derivations for the following structs:
- `SecretKey`
- `KeyPair`
- `SharedSecret`
- `Scalar`
- `DisplaySecret`
This is *only* a Zeroize impl, and does not make Zeroize happen automatically on drop (doing that would be a breaking change because it would preclude deriving `Copy`). But this is still useful, because it allows downstream libraries to implement `ZeroizeOnDrop` for structs that contain such secrets and/or simply to use the `Zeroizing` container struct.
Because these new impls are never invoked automatically, performance impact should be zero. Safety-wise, the `Zeroize` library appears to be widely used in cryptographic code. For example, Supranational's [blst](https://github.com/supranational/blst) Rust bindings use it, and in turn are used in one of the most popular eth2 validator implementations.
Thanks for maintaining a really great library!
ACKs for top commit:
tcharding:
FWIW ACK 8fffbeab13
apoelstra:
ACK 8fffbeab13
Tree-SHA512: 28d2cdcc6bd2d2d6330b67ae8635561882e869199d8fef9a3ebc3f368a7a0c2c00b818281190133f551b099e9c5226f104a56edc14c9b6f699ceba49e4b24563
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]
Tobin C. Harding
Andrew Poelstra
isaac-asdf
Matt Corallo
Thomas DuBuisson
kwantam