> 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?
Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Update EmptyComment.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6380/files - new: https://git.openjdk.java.net/jdk/pull/6380/files/5198d657..33617622 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6380&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6380&range=00-01 Stats: 50 lines in 1 file changed: 27 ins; 11 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/6380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6380/head:pull/6380 PR: https://git.openjdk.java.net/jdk/pull/6380
