Andrea Cosentino created CAMEL-25023:
----------------------------------------
Summary: 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-zipfile, camel-tarfile
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
Fix For: 4.18.5, 4.23.0, 4.22.2
{{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)
