8277087: ZipException: zip END header not found at ZipFile#Source.findEND #6380
Conversation
|
👋 Welcome back serb! A progress list of the required criteria for merging this PR into |
Webrevs
|
| } | ||
| this.comment = bytes; |
There was a problem hiding this comment.
The implementation change looks okay. I assume this regression slipped through due to lack of tests.
The method description doesn't make it clear that the comment can be null (ZipEntry.setComment has the same issue) so we should fix this while we are in the area, as a separate JBS of course as it will need a CSR to track the spec clarification.
There was a problem hiding this comment.
ZipEntry::setComment indicates that the comment will be truncated if needed and ZipOutputStream takes care of this.
Perhaps writeEND() should also be updated to something like:
writeBytes(comment, 0, Math.min(comment.length, 0xffff))
Which is similar to what happens in writeCEN
Yes it would be nice to clarify that a null is accepted by setComment. When null is specified, the comment length is written as 0
There was a problem hiding this comment.
Yes it would be nice to clarify that a null is accepted by setComment. When null is specified, the comment length is written as 0
@mrserb Are you taking the spec clarification or should we just created another issue in JBS to track it?
There was a problem hiding this comment.
I would like to update the spec for the null value for this method, and probably others in a separate CR, since this fix could be backported to the early releases. Will create such CR after agreement.
There was a problem hiding this comment.
I have filed a separate issue: https://bugs.openjdk.java.net/browse/JDK-8277495
There was a problem hiding this comment.
Thank you again for this patch.
There appears to be a similar test, open/test/jdk/java/util/zip/ZipFile/Comment.java, I think we probably want to fold your changes into the existing test and possibly convert to use TestNG. If you prefer to keep this test separate, the test should have expanded coverage to validate that a comment that is set can be successfully read back and the test should be renamed as it does more than just validate an Empty/null comment.
I am also thinking that we should change line 314 of ZipOutputStream::writeEND:
if (comment != null) { // zip file comment
writeShort(comment.length);
writeBytes(comment, 0, comment.length);
} else {
writeShort(0);
}
To be:
writeBytes(comment, 0, 0, Math.min(comment.length, 0xffff));
Which is done when writing an entry comment out in writeCEN.
I know that test, and I explicitly created a new one, since the old one covers the positive cases of reading the different comments from the data by the ZipFile including an empty comment. This one is different, it checks the different use-cases all of which cause to save the empty comment into the data.
It is already checked by the ZipFile test cases.
It has a different implementation because of different specifications, the writeCEN codepath specified to cut long comments and save the first part, this method specified an exception to be thrown if a comment is too long-> an empty comment is saved. |
Sorry if my point was not clear. I would prefer to have 1 test to exercise a Zip file comment vs have tests in multiple areas. Expanding the existing test in this case keeps the primary coverage in one location and makes it easier for future maintainers. There is no reason to not enhance existing tests to add additional coverage.
You are talking about the difference between the javadoc for ZipOutputStream::setComment and ZipEntry::setComment and yes I am aware of the difference. I am not suggesting to not make your change, I am suggesting to include this change as well. |
I have preferred to have separate tests for the separate use cases, other than one big testcases which cover all possible combinations of exceptions and parameters.
I understood that you suggest adding this additional change as well, and I pointed out why it is not necessary, if that code will be executed with the long comment it will break the specification. |
This is really a style choice so I guess we can agree to disagree. Either way it would be preferable to have both tests in the same location.
The additional change simply helps provide a layer of extra protection from corruption creating the zip file. Anyways, I will approve the changes as they are. |
|
@mrserb This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 45 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
|
/integrate |
|
Going to push as commit e3243ee.
Your commit was automatically rebased without conflicts. |
openjdk
bot
added
integrated
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 refactoring, and note:
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?
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6380/head:pull/6380$ git checkout pull/6380Update a local copy of the PR:
$ git checkout pull/6380$ git pull https://git.openjdk.java.net/jdk pull/6380/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 6380View PR using the GUI difftool:
$ git pr show -t 6380Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6380.diff