3d1ce0d261 Truncate secret hash using precision (Tobin C. Harding)
4b143d6f9c Remove bitcoin_hashes range dependency (Tobin C. Harding)
Pull request description:
The `core:#️⃣:Hasher` and `bitcoin_hashes` hash types implement formatting traits slightly differently
- We default to displaying in hex but `core` defaults to using base 10
- We truncate with precision not width parameter but core truncates with both
Anywho, this PR fixes the secret display truncation.
ACKs for top commit:
Kixunil:
ACK 3d1ce0d261
apoelstra:
ACK 3d1ce0d261 successfully ran local tests
Tree-SHA512: f4f15c084f33bf270eab7b578891b50aa743caac12eb0cc3f7ced8fce2df2af93fcca859a2bc0a50396434514fad63368cd81753b8634a41dc3da996d1b1996c
Currently we are attempting to truncate the hash created using
`bitcoin_hashes` by using the "width" formatting parameter instead of
the "precision" parameter. `hex-conservative` truncates with the
"precision" parameter as is expected since a hash is not an integral
type.
Use the formatting string `"{:.16}"` which is the "precision"
formatting parameter.
dc3fc0919d rustfmt: Use show_parse_errors (Tobin C. Harding)
Pull request description:
Clear deprecation warning by using the new option.
ACKs for top commit:
apoelstra:
ACK dc3fc0919d successfully ran local tests
Tree-SHA512: 3277d832d71a8d9ca773c1a0dd54ca79435c703a80994b3512c5a781b1a4e56ecf21639d9e0bc12b60b984b4ccf2201c532b4c7df52c012e1f507f8d0bc607b8
1b0c79ce90 Remove check-for-api infrastructure (Tobin C. Harding)
Pull request description:
This was a short lived, and unfortunately unsuccessful experiment on how to catch API breaking changes. As we did elsewhere in the org, remove the check-for-api infrastructure.
ACKs for top commit:
apoelstra:
ACK 1b0c79ce90 successfully ran local tests
Tree-SHA512: 0fddf186d37af3863428af80ff5c5a941b0d1b40fd4d72b6c1bcf8dec1cb4127446d4d61e19cc12e2ff35a5cd3f98dce0980f913cc38a947dc4d12605b8bebe8
This was a short lived, and unfortunately unsuccessful experiment on how
to catch API breaking changes. As we did elsewhere in the org, remove
the check-for-api infrastructure.
72e09c1a7c Improve the comment on `Message::from_digest` (Martin Habovstiak)
Pull request description:
Minor improvement on top of #712
ACKs for top commit:
apoelstra:
ACK 72e09c1a7c
Tree-SHA512: 06e8e706bb9732ea46ef3488ed33f7c7c84ea5afa5b1b2bca03cd2641524ff61156133436c1dd62df62769c8544644e1a4453fbacf4413fece73282ae154a387
The example claimed it'd be unsafe, which is a specific Rust term and
thus confusing. It'd just be cryptographically broken. Also the example
passes in a constant which looks ridiculously unrealistic.
Fix these by
* changing the comment to say cryptographically broken
* making the example pass the input through invisible fake hash function
939bf9ed5e Deprecate `Message::from_digest_slice` (Martin Habovstiak)
13c5366238 Use `hex_lit::hex` in tests (Martin Habovstiak)
Pull request description:
Closes#710
On top of #709
ACKs for top commit:
apoelstra:
ACK 939bf9ed5e
Tree-SHA512: 34afc2c040e84745881d8d6d250e6fbe5a42b0fcd4dc3ea01579c52948b6ab89d31eb0ffd449d322ec1fe2c7076c05e5b6343a3e1821eae62fd0c13db926f228
All sensible hash engines return arrays, not slices or other things,
therefore `Message::from_digest_slice` is most likely entirely unneeded
since the array version does a better job and in those rare cases where
it is, the users can just call `.try_into()` themselves.
This commit deprecates `from_digest_slice` and changes all tests to use
`from_digest` except the test that tests `from_digest_slice`. It also
simplifies its code to use `try_into` rather than convert manually and
inefficiently.
The tests defined custom `hex!` macros (yes, two actually) that
evaluated to `Vec<u8>`. While the performance didn't matter it made it
harder to use with interfaces that require arrays and all current uses
were passing it as slices anyway.
So, in preparation for upcoming changes, this commit introduces
`hex_lit` dev-dependency which evaluates to array allowing better
interaction with type checker.
55c2efc320 Bump MSRV to 1.63 (Martin Habovstiak)
Pull request description:
The version 1.63 satisfies our requirements for MSRV and provides significant benefits so this commit bumps it. This commit also starts using weak dependencies.
ACKs for top commit:
tcharding:
ACK 55c2efc320
Tree-SHA512: 565fd46768384e7c026c3aa8873e321a20425a6526bcd379ba442cf2504517a435c6c14e21186b36c99185d0a8439f4de2d3ba097b91119483d1a83ab05010ba
The version 1.63 satisfies our requirements for MSRV and provides
significant benefits so this commit bumps it. This commit also starts
using weak dependencies.
df98b160d8 Make schnorr sign/verify accept a message slice (Elichai Turkel)
Pull request description:
As discussed on https://github.com/rust-bitcoin/rust-secp256k1/issues/702 and on IRC,
BIP340 has evolved from supporting only "pre-hashed" 32 byte messages, to supporting messages of "any length" and as such we should allow the users to pass a message of any length.
Note that passing exactly 32 bytes will make the API behave exactly as before (ie it will produce the same signatures).
I added all the test vectors from: https://github.com/bitcoin/bips/blob/master/bip-0340/test-vectors.csv To make sure the API is correct even for empty messages and shorter/longer ones :)
ACKs for top commit:
Kixunil:
ACK df98b160d8
apoelstra:
ACK df98b160d8 thanks for all the new test vectors\!
Tree-SHA512: bd99ea8e17fcc6fd71ad39a87c7c21761f325006998a61b33b6f2abc9f892f90a4236bd25615cb34dc83214a70dcdd34ce3e7cece7d6f971c3843505356c97c5
The `no_std` test disables `std`, so unwinding is unsupported, so we use
`panic = "abort"` but the `core` library is compiled with unwind by
default which breaks the build. Xargo can handle this by recompiling
`core` with `panic = "abort"` so we use it.
Previously we had dependency problems that were resolved by resolver v2.
We want to activate it just in case it happens again but even better,
bump the edition. This was probably forgotten when other crates were
migrated.
Rust is now checking cfg attributes for typos but this interferes with
our cfgs that rustc/cargo don't recognize. This whitelists them so they
no longer produce warnings.
This is a legacy constant and it's better to just use `i32::MAX`. Note
that one cannot `use` an associated constant so this just removed the
import. This is better anyway since it's only used once and it didn't
provide meaningful line length reduction.
5f9baaa7d5 Bump version to 0.29.0 (Tobin C. Harding)
Pull request description:
In preparation for release add a dummy changelog entry and bump the version.
ACKs for top commit:
apoelstra:
ACK 5f9baaa7d5
Tree-SHA512: 1c58dfbc5c55402aae25e50ff096b7af0cc3d85fef05297f597edea264f9a7534983a2a9e79c15e6514142321c71ea8b48a8b80da960e933d2a155162e6e41b4
2bba8f9f5a secp256k1-sys: Vendor latest secp256k1 (Tobin C. Harding)
Pull request description:
Vendor latest tagged version of `secp256k1` and prepare for release:
- Bump the version number to `0.10.0`
- Run the vendor script (vendoring `secp256k1 0.4.1`)
- Update lock files
- Add changelog entry
- Depend on new version in `secp256k1/Cargo.toml`
ACKs for top commit:
apoelstra:
ACK 2bba8f9f5a
Tree-SHA512: 86ab44574d31657f0c99d32a7cf950a54deda4eac6f67ab08cb08a04aa60e65e268893fc1d158fb9895745963c687416c0158e693250d41cefdaf2b71583ff96
Vendor the latest secp256k1 `v0.4.1`. Bump the version number of
`secp256k1-sys` to `v0.10.0` and run the vendor script.
Also depend on the new version in `rust-secp256k1`, and add a changelog
entry.
9f28cf6ad0 Deprecate ThirtyTwoByteHash (Tobin C. Harding)
88c8c58d8d Fix import warnings (Tobin C. Harding)
Pull request description:
The implementations of `ThirtyTwoByteHash` for types from the `hashes` crate are problematic during upgrades because both `bitcoin` and `secp256k1` depend on `hashes` and when the versions of `hashes` get out of sync usage of the trait breaks.
Deprecate the `ThirtyTwoByteHash` trait and remove the impls for types from `bitcoin_hashes`.
Add an explanation in the changelog because its too long to go in the deprecation message.
Close: #673
ACKs for top commit:
apoelstra:
ACK 9f28cf6ad0
Tree-SHA512: a7598b09c6a2f49913a9effad3e1ed9b0663970ac20fbfe5fc2f1329daaa2b4cab78b00128a03d0f3f6559ed7964b09e0bd939e60cf130b2cc6e609c90df6868
The implementations of `ThirtyTwoByteHash` for types from the `hashes`
crate are problematic during upgrades because both `bitcoin` and
`secp256k1` depend on `hashes` and when the versions of `hashes` get
out of sync usage of the trait breaks.
Deprecate the `ThirtyTwoByteHash` trait and remove the impls for types
from `bitcoin_hashes`.
Add an explanation in the changelog because its too long to go in the
deprecation message.
645271dd74 Upgrade hashes dependency (Tobin C. Harding)
Pull request description:
Keep the range versioning but increase the threshold to include the latest `v0.14.0` release.
ACKs for top commit:
apoelstra:
ACK 645271dd74
Tree-SHA512: 46c93e4ad4077cc164e546fd9621f18ec34c2e110f9c763e8252d3ee92174e9efb5a20eea6169f62d5397fcbab5799dd8d9c88577bbf246e9aa4c2b2282c2266
2d0c7835f1 Tighten the version grep in vendor script (Tobin C. Harding)
a2b78f4022 Bump MSRV to 1.56.1 (Tobin C. Harding)
Pull request description:
As we have done in other parts of the ecosystem bump the MSRV to Rust `v1.56.1`.
Done for `secp256k1` and `secp256k1-sys`.
This was originally in #688 but there are too many things going on so here it is separately.
ACKs for top commit:
apoelstra:
ACK 2d0c7835f1
Tree-SHA512: 35ac5632428211b02f5b25780c3a680d8c9a68b238de7299242510091f9243fe2f6718817c865c3420e3afb64b32d52daf2cf372706067204e7de42e188c31c6
We just added `rust-version = ` to the `secp256k1-sys` manifest, doing
so causes a grep statement from the vendor script to match this line -
we don't want that.
Tighten up the grep statement by only matching on `version` at the start
of the line.
0da394e648 Remove wildcard re-exports of key types (Tobin C. Harding)
d63e95b99b Remove wildcard re-exports of context types (Tobin C. Harding)
Pull request description:
Wildcards make it hard to grep for where stuff comes from, explicit imports and re-exports are ... more explicit.
- Patch 1: Re-export the `context` types explicitly.
- Patch 2: Re-export the `key` types explicitly.
Fix: #681
ACKs for top commit:
apoelstra:
ACK 0da394e648
Tree-SHA512: ac92baa9b9abaaff436223bf1d18d286825dbfc8eef401c714314902ff471db4830dce360138845efd781bcb883676d0cbc3db8d691476403eb487a0585edeaa
7b6a13b004 CI: Revert cc pin in ASAN job (Tobin C. Harding)
Pull request description:
Revert commit: 92778efe92
We can't use git to revert it because the code has now moved from `test.sh` to `_test.sh`.
I don't remember the problem but lets just use CI to see if its fixed.
ACKs for top commit:
sanket1729:
utACK 7b6a13b004
apoelstra:
ACK 7b6a13b004
Tree-SHA512: d804c73152b3d8b14e8f13e64066c33e2dfbdef8b184d55672638df6b468a6f636e632c5e1a0b09e617534aaf466b1c719c6df16952aaf8a51cb2659bed1d0ef
65d54e7bbe Add script to update-lock-files (Tobin C. Harding)
c61db1b44f CI: Check for API changes (Tobin C. Harding)
53d34d5ee0 Update the API files (Tobin C. Harding)
c3f2c59db1 just: Add a command to check for API changes (Tobin C. Harding)
1e22d74270 Add a justfile (Tobin C. Harding)
Pull request description:
This PR is not just CI, it does a few clean up chores:
- Add a `justfile` (including command to check the API)
- Update the API files
- Add a script to update the lock files
ACKs for top commit:
apoelstra:
ACK 65d54e7bbe
Tree-SHA512: c799200dc761cb4367904346024834caf52e9a549aed5741263429d0bd297858c5293bfdb4bdf83fffb063060f7f251c9c1956659bd50867b09fafddb3c54880
Wildcards make it hard to grep for where stuff comes from, explicit
imports and re-exports are ... more explicit.
Re-export the `key` types explicitly.
Wildcards make it hard to grep for where stuff comes from, explicit
imports and re-exports are ... more explicit.
Import and re-export explicitly instead of by using wildcards.
Revert commit: 92778efe92
We can't use git to revert it because the code has now moved from
`test.sh` to `_test.sh`.
I don't remember the problem but lets just use CI to see if its fixed.
Andrew Poelstra
Tobin C. Harding
Martin Habovstiak
Marko Bencun
Elichai Turkel