[
https://issues.apache.org/jira/browse/CAMEL-25023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18121220#comment-18121220
]
Andrea Cosentino commented on CAMEL-25023:
------------------------------------------
The fixVersions listed 4.18.5 and 4.22.2, but the fix was not on either branch
- both still counted in an int, so the maxSize guard behind maxDecompressedSize
was bypassable there. Verified by reverting the fix on each branch:
testCopyMaxSizeOfTwoGigabytesOrMore fails with "maxSize 2147483547 was not
enforced" and testCopyMoreThanTwoGigabytes returns -1073741824.
Backports opened:
* camel-4.22.x: https://github.com/apache/camel/pull/27137
* camel-4.18.x: https://github.com/apache/camel/pull/27138
Both are straight cherry-picks of #26892 (code and test only; the upgrade-guide
entry stays on main). Leaving this issue In Progress until they merge.
_Claude Code on behalf of oscerd_
> camel-util - IOHelper.copy counts copied bytes in an int, so zipFile/tarFile
> maxDecompressedSize values of 2 GiB or more are not enforced
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25023
> URL: https://issues.apache.org/jira/browse/CAMEL-25023
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-tarfile, camel-zipfile
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.18.5, 4.22.2, 4.23.0
>
>
> {{IOHelper.copy(InputStream, OutputStream, int bufferSize, boolean
> flushOnEachWrite, long maxSize)}} keeps its running byte count in an {{int}}:
> {code:java}
> int total = 0;
> ...
> total += n;
> if (maxSize > 0 && total > maxSize) {
> throw new IOException("The InputStream entry being copied exceeds the
> maximum allowed size");
> }
> {code}
> An {{int}} cannot exceed {{Integer.MAX_VALUE}} and wraps to a negative value
> after 2 GiB, so a {{maxSize}} of {{Integer.MAX_VALUE}} or larger (or within
> one read buffer below it) never triggers the check. The {{int}} return value
> is also negative for copies larger than 2 GiB.
> This overload implements the {{maxDecompressedSize}} option of:
> * {{ZipFileDataFormat.unmarshal}} ({{usingIterator=false}})
> * {{ZipIterator}} / {{ZipSplitter}} ({{usingIterator=true}}, since
> CAMEL-24166)
> * {{TarFileDataFormat.unmarshal}} ({{usingIterator=false}})
> {{maxDecompressedSize}} is a {{java.lang.Long}} option; the 1 GiB default is
> enforced correctly, but values of 2 GiB or more are currently ignored.
> {{TarIterator}} is not affected, as it uses a long-based
> {{BoundedInputStream}}.
> Proposed change:
> * count in a {{long}} and return {{(int) Math.min(total,
> Integer.MAX_VALUE)}}, keeping the public signature;
> * regression test in {{IOHelperTest}}: copy 3 GiB of synthetic zeros into a
> discarding {{OutputStream}} with {{maxSize}} = 2 GiB and expect the
> {{IOException}} (needs no heap or disk).
> _Claude Code on behalf of oscerd_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
