On Sat, 13 Nov 2021 23:16:22 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:

> The ZipOutputStream class may create bogus zip data which cannot be opened by 
> the ZipFile. The root cause is how the comment field is stored by the 
> ZipOutputStream. According to the zip specification, the comment field should 
> not be longer than 0xFFFF bytes, and we try to validate the length of the 
> comment, but unfortunately, we do this after the comment was assigned 
> already. So if the application saves the comment based on the user's input 
> and then gets an exception from the ZipOutputStream.setComment() it may 
> assume that the comment is too long and it will be ignored, but it will be 
> saved as-is to the file.
> 
> Please take a look at 
> [this](https://github.com/openjdk/jdk/commit/c435a0905dfae827687ed46015269f9c1b36c239#diff-736e247f0ec294323891a77e16a9f0dba8bc1872131c857edf18c3f349e750eeL117)
>  refactoring, and note:
>  * The comment field is assigned before the length check
>  * The null comment is ignored
> 
> The current fix will move the length validation before being assigned and 
> will use the null comment as an empty text. Note that the behavior of the 
> null parameter is not specified in the method/class/package so we are free 
> here to implement it in any way, any thoughts/suggestions on which is better?

test/jdk/java/util/zip/ZipOutputStream/EmptyComment.java line 88:

> 86:             byte[] data = baos.toByteArray();
> 87:             // Since the comment is empty this will be two last bytes
> 88:             int pos = data.length - ZipFile.ENDHDR + ZipFile.ENDCOM;

I would probably check that I could find Phil Katz' initials at data.length - 
ZipFile.ENDHDR

test/jdk/java/util/zip/ZipOutputStream/EmptyComment.java line 95:

> 93:         }
> 94:     }
> 95: }

Every source file should end in exactly one newline

-------------

PR: https://git.openjdk.java.net/jdk/pull/6380

Reply via email to