Fix wallet:transaction decrypting at most 255 notes #3950
Merged
Conversation
This file contains 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
|
how can i update node version? what is the commands? |
jowparks
pushed a commit
that referenced
this pull request
Jun 21, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Fixes a bug where calling
wallet:transactionorwallet:transactionson a transaction with more than 255 output notes would only display at most the first 255 results.The decryptNotes task passes in the number of notes to decrypt as a u8, but bufio only bounds-checks if a number is a safe integer when writing numbers, and we don't do any verification that the number of results matches the number of inputs, so it's possible to overflow the value. In the wallet's transaction processing code, we decrypt notes in batches of 20, so this doesn't affect it. But when calling
wallet:transactionorwallet:transactions, we attempt to decrypt output notes as a spender in one batch, and since transactions can have several hundred notes, this opens up the possibility for this bug.The PR's change removes the length field from the serialized output -- since the worker pool is internal to the SDK and nothing external can connect to it, I don't think it's necessary to encode the number of notes as part of the input.
This doesn't affect a user's balance or available notes in their wallet, and transactions don't need to be rescanned or re-decrypted as a result of this change. Also, incoming/received notes are not affected by this, so this bug would only affect display of transactions where the decrypting account sent more than 255 notes.
Testing Plan
Documentation
Does this change require any updates to the Iron Fish Docs (ex. the RPC API
Reference)? If yes, link a
related documentation pull request for the website.
Breaking Change
Is this a breaking change? If yes, add notes below on why this is breaking and
what additional work is required, if any.