5-byte padding

[ulikunitz]

5-byte padding

[ulikunitz]

Hi, thank you for reporting the problem. The xz specification says that the padding of a block header should be not greater than 3. However it appears that there are files in the wild with a padding of 4 or 5. I have already removed the padding size in the test code and could successfully extract the file.

It will take a little bit longer for a release.

[ulikunitz]

Release 0.5.4 fixes the issue.

[langbeck]

@ulikunitz I use your lib in my work and I must say that it's awesome and I do appreciate the effort that you put in your work. Said that...

I think such restriction doesn't exists. The only restriction seems that all bytes left, after List of Filter Flags had been read, must be zeroes. This seems to be true in all five specs at: https://tukaani.org/xz/format.html

3.1.6. Header Padding

        This field contains as many null byte as it is needed to make
        the Block Header have the size specified in Block Header Size.
        If any of the bytes are not null bytes, the decoder MUST
        indicate an error. It is possible that there is a new field
        present which the decoder is not aware of, and can thus parse
        the Block Header incorrectly.

[ulikunitz]

You are right. It seems that I confused it with the block padding.

3.3. Block Padding

        Block Padding MUST contain 0-3 null bytes to make the size of
        the Block a multiple of four bytes. This can be needed when
        the size of Compressed Data is not a multiple of four. If any
        of the bytes in Block Padding are not null bytes, the decoder
        MUST indicate an error.

I create an issue as a reminder.