-
Notifications
You must be signed in to change notification settings - Fork 745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - Limit snappy input stream #1738
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice test and good changes, but think I found a minor bug in the same code. Metadata requests should be 0 bytes, but it looks like the length bytes are still read.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good. Nice work!
Although a little more effort, I think we might benefit from implementing an RPC Limit struct type with max
and min
fields rather than the tuple.
I think it will make the code a little more readable and hopefully prevent mixing up the tuple indexes when doing things like length > limit.1 || length < limit.0
What do you think?
Agree this is ugly. Will make the changes :) |
bors r+ |
## Issue Addressed N/A ## Proposed Changes This PR limits the length of the stream received by the snappy decoder to be the maximum allowed size for the received rpc message type. Also adds further checks to ensure that the length specified in the rpc [encoding-dependent header](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#encoding-strategies) is within the bounds for the rpc message type being decoded.
Pull request successfully merged into master. Build succeeded: |
Issue Addressed
N/A
Proposed Changes
This PR limits the length of the stream received by the snappy decoder to be the maximum allowed size for the received rpc message type. Also adds further checks to ensure that the length specified in the rpc encoding-dependent header is within the bounds for the rpc message type being decoded.