I finally got around to researching this issue in the tracker.

Issue 10298 is a close relative to this issue.  The fix from that issue make the test that Xuanji added here pass.  That issue contains no tests....it would be ideal to have tests that test the behavior in the face of actual comments in the zipfile, but even if all we have is Xuanji's test IMO we should apply one of the two fixes.

The 10298 patch takes the approach of ignoring the excess data but preserving the comment if any.  The author implies that that is what other tools do, so in the absence of input from Alan or other zipfile experts that's probably what we should go with.

Rep, could you look over this issue and indicate if you agree?

Note also issue 9239, which fixes one way that zipfile could create a zipfile with garbage at the end.

Then there is issue 1757072, where we hear some of Alan's thinking about this: a "non-strict" mode...but it is perhaps too late for a feature request, and there is the fact that ignoring the trailing data appears to be a de-facto standard.

And then we have issue 1757072, which is identical to this one and was closed won't fix, but apparently only because the source of the corrupted zip files wasn't identified, which this issue does do.

Interestingly, issue 669036 claims that zipfile.py supports garbage at the start, which makes tolerating garbage at the end seem sensibly symmetric.

Finally, comment support was added by the patch in issue 611760.  It would be interesting to know if garbage at the end was supported before that patch.  My guess is that it was, by ignoring it, but I haven't tested it.

Summary: if someone can review the actual patch, I think we should apply the issue 10298 patch along with Xuanji's test.  Xuanji, if you have the time and desire to add some additional tests that test comments with trailing data, that would be a bonus.  You could look at the tests in issue 9239 for ideas.