oscerd opened a new pull request, #27137:
URL: https://github.com/apache/camel/pull/27137
Backport of #26892 (CAMEL-25023) from `main`.
The Jira already carried `4.22.2` in its fixVersions, but the fix was not on
this branch — so the release notes promised something that had not shipped.
This closes that.
### Why it matters on this branch
The `maxSize` guard in `IOHelper.copy(InputStream, OutputStream, int,
boolean, long)` **is present here and is bypassable**. The byte counter behind
the check was an `int`, so a `maxDecompressedSize` of 2 GiB
(`Integer.MAX_VALUE`) or more wrapped to a negative value and the check never
fired. That is the zip/tar-bomb guard used by the Zip File and Tar File data
formats and by `ZipSplitter`.
Verified by reverting the fix on this branch and running the ported tests:
```
IOHelperTest.testCopyMaxSizeOfTwoGigabytesOrMore maxSize 2147483547 was not
enforced
==> Expected
java.io.IOException to be thrown, but nothing was thrown.
IOHelperTest.testCopyMoreThanTwoGigabytes expected: <2147483647> but
was: <-1073741824>
```
With the fix applied, `IOHelperTest` is 5/5 green.
### Scope
Straight cherry-pick of the code and test. The only conflict was
`camel-4x-upgrade-guide-4_23.adoc`, which does not exist on this branch; it is
dropped here because upgrade guides for every release line live on `main`. A
follow-up doc-sync adds the matching entry to the `4_22`/`4_18` guide on `main`.
The method still returns an `int`, now clamped to `Integer.MAX_VALUE`
instead of a wrapped negative.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
