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"
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
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 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]
As we did in rust-bitcoin [0] create a configuration conditional `bench`
that we can use to guard bench mark code. This has the benefit of
making our features additive i.e., we can now test with `--all-features`
with a stable toolchain (currently this fails because of our use of the
`test` crate).
[0] - https://github.com/rust-bitcoin/rust-bitcoin/pull/1092
Add `githooks` directory and:
- Copy the default pre-commit hook into new githooks directory
- Add a call to clippy to the pre-commit hook
- Add a section to the README instructing devs how to use the new
githooks
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.