On Fri, 26 Jan 2024 20:49:57 GMT, Lance Andersen wrote:
>> To help make progress here, I have relaxed the validation such that we now
>> check:
>>
>> - That the "streaming mode" bit 3 flag is set
>> - That at least one of the LOC's size fields are marked 0x.
>> - That the LOC extra fiel
On Mon, 5 Feb 2024 13:14:39 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data des
On Mon, 5 Feb 2024 12:31:37 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 228 commits:
>>
>> - Merge branch 'master' into data-descriptor
>> - Update comment of expect64BitDataDescrip
On Mon, 5 Feb 2024 13:14:39 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data des
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Fri, 26 Jan 2024 14:32:58 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Fri, 26 Jan 2024 14:32:58 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Fri, 26 Jan 2024 14:34:39 GMT, Eirik Bjørsnøs wrote:
> To help make progress here, I have relaxed the validation such that we now
> check:
>
> * That the "streaming mode" bit 3 flag is set
> * That at least one of the LOC's size fields are marked 0x.
> * That the LOC extra field has
On Fri, 26 Jan 2024 14:32:58 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Mon, 22 Jan 2024 14:34:25 GMT, Eirik Bjørsnøs wrote:
> @LanceAndersen Do you have a cent or two to spare?
Let me try and dig out from a couple of things and circle back to this again
-
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1462519461
On Tue, 16 Jan 2024 14:55:39 GMT, Jaikiran Pai wrote:
> I think the only role that a zip64 block should play when we are deciding how
> to parse a data descriptor is whether or not the entry has zip64 extra field
> set (the header id value of the extra field). Does that sound reasonable?
Are y
On Tue, 16 Jan 2024 14:41:06 GMT, Eirik Bjørsnøs wrote:
> The spec isn't terribly helpful in spelling out what should happen in the
> case where an entry combines the uses of data descriptors (mandating that
> CRC, size and compressed size must be zero) with Zip64 (mandating that size
> and co
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Tue, 16 Jan 2024 13:54:06 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove trailing whitespace
>> - Remove trailing whitespace
>
> src/java.base/share/classes/java/util/zip/ZipInputS
On Tue, 16 Jan 2024 14:34:29 GMT, Eirik Bjørsnøs wrote:
>(These reads are from a temp buffer, not the stream)
Ah! you are right indeed. I didn't correctly read that part of that code. It's
reading from a temp buffer which has been fully initialized with a LOC and
these reads happens with speci
On Tue, 16 Jan 2024 14:32:51 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Tue, 16 Jan 2024 13:42:30 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 534:
>>
>>> 532:
>>> 533: long csize = get32(tmpbuf, LOCSIZ);
>>> 534: long size = get32(tmpbuf, LOCLEN);
>>
>> Hello Eirik, I suspect this part of the ch
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Tue, 16 Jan 2024 13:40:18 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove trailing whitespace
>> - Remove trailing whitespace
>
> src/java.base/share/classes/java/util/zip/ZipInputS
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Wed, 10 Jan 2024 17:02:05 GMT, Eirik Bjørsnøs wrote:
>> Sounds like a CSR is needed for the behavioral change proposed here.
>
>> Sounds like a CSR is needed for the behavioral change proposed here.
>
> Thanks for flagging this @jddarcy
>
> I'm personally not 100% convinced a CSR is warrant
On Wed, 10 Jan 2024 17:02:05 GMT, Eirik Bjørsnøs wrote:
> > Sounds like a CSR is needed for the behavioral change proposed here.
>
> Thanks for flagging this @jddarcy
>
> I'm personally not 100% convinced a CSR is warranted in this case, but I'm of
> course happy to extend the following into a
On Mon, 8 Jan 2024 18:21:06 GMT, Joe Darcy wrote:
> Sounds like a CSR is needed for the behavioral change proposed here.
Thanks for flagging this @jddarcy
I'm personally not 100% convinced a CSR is warranted in this case, but I'm of
course happy to extend the following into a CSR if you or ot
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Tue, 9 Jan 2024 13:06:56 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data des
On Tue, 9 Jan 2024 13:06:56 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data des
On Mon, 8 Jan 2024 15:43:34 GMT, Jaikiran Pai wrote:
> The crucial part here is that the "current" `ZipEntry` is the one which was
> created by a previous call to `ZipInputStream.getNextEntry()` method, which
> is a public overridable method. Furthermore, the `ZipEntry.getExtra()` method
> too
On Mon, 8 Jan 2024 15:04:58 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 33 commits:
>>
>> - Merge branch 'master' into data-descriptor
>> - Extract ZIP64_BLOCK_SIZE_OFFSET as a cons
On Mon, 8 Jan 2024 14:59:40 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 33 commits:
>>
>> - Merge branch 'master' into data-descriptor
>> - Extract ZIP64_BLOCK_SIZE_OFFSET as a cons
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Mon, 8 Jan 2024 14:47:48 GMT, Jaikiran Pai wrote:
> With the current proposed change, we not only rely on the Inflater for this
> decision but also rely on ZipEntry itself to tell us whether to read 8 bytes
> or 4 bytes each.
The proposed change resides solely in one single internal/privat
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Sun, 12 Feb 2023 17:04:51 GMT, Alan Bateman wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data desc
On Tue, 28 Nov 2023 18:38:42 GMT, Eirik Bjorsnos wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Extract ZIP64_BLOCK_SIZE_OFFSET as a constant
>
> Thanks for your patient and thorough review of this long-lived PR
On Wed, 15 Nov 2023 20:10:53 GMT, Eirik Bjorsnos wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Wed, 15 Nov 2023 20:10:53 GMT, Eirik Bjorsnos wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Wed, 15 Nov 2023 20:13:15 GMT, Eirik Bjorsnos wrote:
>> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 581:
>>
>>> 579: if ((flag & 8) == 8) {
>>> 580: /* "Data Descriptor" present */
>>> 581: if (hasZip64Extra(e) ||
>>
>> You probably want
On Tue, 14 Nov 2023 11:49:11 GMT, Lance Andersen wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add a @bug reference in the test
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 581:
>
>>
On Mon, 13 Nov 2023 19:02:28 GMT, Lance Andersen wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add a @bug reference in the test
>
> test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java line 57:
>
>>
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Wed, 8 Nov 2023 13:45:14 GMT, Eirik Bjorsnos wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data des
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Wed, 8 Nov 2023 13:20:33 GMT, Eirik Bjorsnos wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data des
On Sat, 28 Oct 2023 17:34:35 GMT, Eirik Bjorsnos wrote:
> We need to hold off this PR until #15650 has been integrated as it impacts
> some of the changes proposed here
Marking this PR ready for review, now that #15650 has been integrated.
A summary of updates after #15650:
- `ZipFile.isZip64
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Sat, 28 Oct 2023 17:08:07 GMT, Eirik Bjorsnos wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Sat, 28 Oct 2023 17:08:07 GMT, Eirik Bjorsnos wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Sat, 28 Oct 2023 17:08:07 GMT, Eirik Bjorsnos wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Tue, 18 Apr 2023 18:19:20 GMT, Lance Andersen wrote:
> It would be useful to obtain the zip/jar in question to validate that your
> proposed patch addresses the issue as well as verifying if ZipfFile can be
> used to process the zip/jar as reading the long thread appears that
> ZipFile:getI
On Tue, 18 Apr 2023 18:24:01 GMT, Eirik Bjorsnos wrote:
> > Do you know how the Zip in question is being created, is it via
> > ApacheCommons and could there be an issue there?
>
> Currently investigating. The Tomcat build is using the Ant `jar` task to
> create the `tomcat-embed-core.jar`, bu
On Tue, 18 Apr 2023 18:19:20 GMT, Lance Andersen wrote:
> Do you know how the Zip in question is being created, is it via ApacheCommons
> and could there be an issue there?
Currently investigating. The Tomcat build is using the Ant `jar` task to create
the `tomcat-embed-core.jar`, but then cal
On Wed, 29 Mar 2023 10:48:57 GMT, Eirik Bjorsnos wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Wed, 29 Mar 2023 10:48:57 GMT, Eirik Bjorsnos wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Sun, 12 Feb 2023 15:41:55 GMT, Eirik Bjorsnos wrote:
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descrip
On Sun, 12 Feb 2023 15:41:55 GMT, Eirik Bjorsnos wrote:
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descrip
On Sun, 12 Feb 2023 17:04:51 GMT, Alan Bateman wrote:
> The current implementation came about because of issues with several zip
> tools so we have to be very careful changing it.
Thanks for providing historical context, that's very useful! Do you happen to
know a few of the zip tools the cur
On Mon, 20 Feb 2023 11:28:29 GMT, Lance Andersen wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Tue, 28 Feb 2023 20:31:43 GMT, Eirik Bjorsnos wrote:
> Thanks a lot for looking into this, Lance!
>
> > Are you aware of any tools that would create this scenario as to the best
> > of my knowledge we have not encountered one that does as of yet?
>
> The following on my Mac produces a Zip64
On Sun, 12 Feb 2023 15:41:55 GMT, Eirik Bjorsnos wrote:
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descrip
On Tue, 28 Feb 2023 20:48:47 GMT, Eirik Bjorsnos wrote:
> > Thanks a lot for looking into this, Lance!
> > > Are you aware of any tools that would create this scenario as to the best
> > > of my knowledge we have not encountered one that does as of yet?
> >
> >
> > The following on my Mac prod
ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number
of compressed or uncompressed bytes read from the inflater is larger than the
Zip64 magic value.
While the ZIP format mandates that the data descriptor `SHOULD be stored in
ZIP64 format (as 8 byte values) when a fil
77 matches
Mail list logo
