fuzz: introduce and use ConsumePrivateKey helper#28419
Merged
fanquake merged 1 commit intobitcoin:masterfrom Sep 7, 2023
Merged
fuzz: introduce and use ConsumePrivateKey helper#28419fanquake merged 1 commit intobitcoin:masterfrom
ConsumePrivateKey helper#28419fanquake merged 1 commit intobitcoin:masterfrom
Conversation
Contributor
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. |
maflcko
reviewed
Sep 6, 2023
theStack
force-pushed
the
202309-fuzz-add_consumeprivkey_helper
branch
from
2d05cd2 to
583af18
Compare
Contributor
|
Concept ACK |
Member
|
utACK 583af18 |
brunoerg
approved these changes
Sep 7, 2023
Frank-GER
pushed a commit
to syscoin/syscoin
that referenced
this pull request
Sep 8, 2023
583af18 fuzz: introduce and use `ConsumePrivateKey` helper (Sebastian Falbesoner) Pull request description: In the course of reviewing BIP324 related PRs I noticed a frequent pattern of creating private keys (`CKey` instances) with data consumed from the fuzz data provider: ``` auto key_data = provider.ConsumeBytes<unsigned char>(32); key_data.resize(32); CKey key; key.Set(key_data.begin(), key_data.end(), /*fCompressedIn=*/true); ``` This PR introduces a corresponding helper `ConsumePrivateKey` in order to deduplicate code. The compressed flag can either be set to a fixed value, or, if `std::nullopt` is passed (=default), is also consumed from the fuzz data provider via `.ConsumeBool()`. Note that this is not a pure refactor, as some of the replaced call-sites previously consumed a random length (`ConsumeRandomLengthByteVector`) instead of a fixed size of 32 bytes for key data. As far as I can see, there is not much value in using a random size, as in all those cases we can only proceed or do something useful with a valid private key, and key data with sizes other than 32 bytes always lead to invalid keys. ACKs for top commit: sipa: utACK 583af18 brunoerg: crACK 583af18 Tree-SHA512: 58a178432ba1eb0a2f7597b6700e96477e8b10f429ef642445a52db12e74d81aec307888315b772bfda9610f90df3e1d556cf024c2bef1d520303b12584feaaa
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In the course of reviewing BIP324 related PRs I noticed a frequent pattern of creating private keys (
CKeyinstances) with data consumed from the fuzz data provider:This PR introduces a corresponding helper
ConsumePrivateKeyin order to deduplicate code. The compressed flag can either be set to a fixed value, or, ifstd::nulloptis passed (=default), is also consumed from the fuzz data provider via.ConsumeBool().Note that this is not a pure refactor, as some of the replaced call-sites previously consumed a random length (
ConsumeRandomLengthByteVector) instead of a fixed size of 32 bytes for key data. As far as I can see, there is not much value in using a random size, as in all those cases we can only proceed or do something useful with a valid private key, and key data with sizes other than 32 bytes always lead to invalid keys.