We just applied a hot fix to the 0.23.0 released code to fix the
features enabled in `rand` when our "rand-std" feature is enabled. This
requires a bump of the patch version for release.
Bump the version and add a changelog entry.
We recently upgraded the rand dependency and we use it behind code
feature gated on "rand-std". In that code we use `thread_rng` but this
is only available if the "std_rng" feature is turned on, however in
non-dev builds we do not enable this feature, we have a "rand-std"
feature that enables "rand/std", it should also enable "std_rng".
Enable "rand/std_rng" in the "rand-std" feature.
Add a `tests` directory. Add `serde` tests for the recently added fixed
width binary serialization code.
Please note, serialization is only fixed width when serialized with
the `bincode` crate.
Currently we use 'no default features' for the `bitcoin_hashes`
dependency. Doing so means that if users want the `std` feature they
need to explicitly add a `bitcoin_hashes` dependency even though we
re-export `bitcoin_hashes` as `hashes`. This means that in the common
case the re-export is pointless. As an example, `rust-bitcoin`
unnecessarily requires an explicit dependency on `bitcoin_hashes`.
Add `bitcoin-hashes-std` feature so that users do not need an explicit
dependency in the common use case.
Change the test matrix to only test '*-std' features when 'std' is
enabled since enabling one without the other is illogical. Please note,
this replaces the test run of feature 'std'+'rand'+'rand-std' with just
'std'+'rand-std' because enabling 'rand-std' enables 'rand' so the
explicit additional feature is redundant.
Currently we use default features for the `bitcoin_hashes` dependency,
doing so breaks the `no-std` feature in `rust-bitcoin` because `std` is
part of `bitcoin_hashes` default feature set.
Disable `bitcoin_hashes` default features, no changes to `rust-bitcoin`
are require after this change since we manually turn on `std` and
`alloc` as part of the `std`/`no-std` features of `rust-bitcoin`.
For other users of `rust-secp256k1` this is a breaking change but is
unlikely to cause too much bother because `std` is so commonly used.
Mirror the whitespacing in `rust-bitcoin` by doing:
- Only use single line of whitespace between sections
- Separate optional dependencies from non-optional ones
65d32af6fd bump version to 0.21.3 (Andrew Poelstra)
Pull request description:
We've got a ton of minor changes in, plus fixing the Parity type and adding some extra serde impls. Let's push a minor version out so that we can move on to updating the upstream libsecp.
Top commit has no ACKs.
Tree-SHA512: 584c03106124b4152b8971ac6d0587a26d2aca9187f88d8228a356c2327bf066d2c9b8134149f9ee3bc5f3712f64559b32843aa8e92d3395c5a1bd53de5442ce
Instead of providing a mechanism for users to opt out of randomization
we can just feature gate the call site i.e., opportunistically randomize
the global context on creation if `rand-std` feature is enabled.
The examples depend on having the "std" feature [1]. In preparation for
being able to run tests with `--no-default-features` add the "std"
feature as a requirement for all three examples. While we are at it use
the correct rand feature requirement: `rand-std`.
[1] Technically we only need "alloc" but "alloc" is not working with
Rust 1.29 currently so just use "std".
e595b39510 Re-export Parity struct (sanket1729)
Pull request description:
pub struct Parity is under a private module key and not re-exported in lib.rs . It is therefore not
possible to use it downstream.
ACKs for top commit:
elichai:
ACK e595b39510
apoelstra:
ACK e595b39510
Tree-SHA512: 2573689f9a08505c8dfe8f79cd921d5a2742a2a2f4f92cf4066fe6557c765c756531d13560fa4fe6461f094b0c11a52aca30b44542eb77eda7dd1ebd24d3b155
18f74d5242 Clarify what does "less security" mean (Martin Habovstiak)
94c55b4d09 Fixed typos/grammar mistakes (Martin Habovštiak)
1bf05523f0 Documented features (Martin Habovstiak)
Pull request description:
This documents the Cargo features making sure docs.rs shows warning for
feature-gated items. They are also explicitly spelled out in the crate
documentation.
The PR is similar in spirit to https://github.com/rust-bitcoin/rust-bitcoin/pull/633
ACKs for top commit:
apoelstra:
ACK 18f74d5242
Tree-SHA512: 8aac3fc5fd8ee887d6b13606d66b3d11ce44662afb92228c4f8da6169e3f70ac6a005b328f427a91d307f8d36d091dcf24bfe4d17dfc034d02b578258719a90a
This documents the Cargo features making sure docs.rs shows warning for
feature-gated items. They are also explicitly spelled out in the crate
documentation.
bc42529a16 Rename `secp256k1::bitcoin_hashes` module to `secp256k1::hashes` (Thomas Eizinger)
ae1f8f4609 Bump bitcoin_hashes to version 0.10 (Thomas Eizinger)
Pull request description:
Requires for interoperability of the `ThirtyTwoByteHash` trait with
rust-bitcoin.
ACKs for top commit:
apoelstra:
ACK bc42529a16
Tree-SHA512: 85fcb284ff82b543a0c3ea2b568351b3af938a26ac42c6a975480ae97def84e4f0795105bd4572f930a7bf82654eba416cf0c5e25f62809e2ea331443ffb5807
It's super dangerous to use Cargo features for this, since they can be set
accidentally (or maliciously by any crate in a user's entire dep tree). Instead
we can just require users set `RUSTFLAGS` appropriately, which we can easily
do in our fuzzing scripts.
This feature was not useful for Cargo users, since Cargo does not give you
the kind of fine-grained control over C library linkage that you need. So
it was just unnecessarily confusing and would cause the build to break if
you enabled it accidentally, say, with --all-features.
Artem Vorotnikov
Tobin C. Harding
Andrew Poelstra
Elichai Turkel
Dominik Spicher
Martin Habovstiak
sanket1729
Thomas Eizinger
Dr Maxim Orlovsky
Devrandom
Matt Corallo
Tibo-lg