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
76 matches
Mail list logo
