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
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
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
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
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
> 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
