dxbjavid opened a new pull request, #3605: URL: https://github.com/apache/thrift/pull/3605
TCompactProtocol.readBinary only checks the binary length against the remaining message budget, so the per-string limit (stringLengthLimit) that readString applies through checkStringReadLength is never enforced for binary fields. a peer that has configured a string length limit therefore has it quietly bypassed for any binary value, which can then be sized up to the whole message. routing readBinary through checkStringReadLength applies the same limit and keeps the existing remaining-bytes check, matching how TBinaryProtocol.readBinary already behaves. added a regression test alongside the existing compact string-limit test. - [ ] Did you create an [Apache Jira](https://issues.apache.org/jira/projects/THRIFT/issues/) ticket? ([Request account here](https://selfserve.apache.org/jira-account.html), not required for trivial changes) - [x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"? - [x] Did you squash your changes to a single commit? (not required, but preferred) - [x] Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"? - [ ] If your change does not involve any code, include `[skip ci]` anywhere in the commit message to free up build resources. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
