According to this issue (#48) with the node library yauzl, and discussed here, there is a flaw with the zip specification, and it is easy for invalid zip files to be created.
The high-level structure of a .zip file dictates that a reader must first look for the End of Central Directory Record, which is located at the very end of a .zip file. The final field of the End of Central Directory Record is a variable-length comment. The length of the comment is recorded in a field in the End of Central Directory Record before the comment itself. ... literally the only way to find the End of Central Directory Record is to use heuristics to guess where the zipfile creator meant for it to be. The .zip file specification is ambiguous; it is flawed.
yauzl searches backwards for the magic number, and once it is found, yauzl does some additional checking to make sure this magic number is actually part of an End of Central Directory Record. This check involves sanity checking all the fields in the End of Central Directory Record, including verifying that the comment length field is correct. If any of the fields look fishy, the zipfile is rejected.
Currently invalid zip files throw the "invalid comment length" error in yauzl (and possibly other spec-conforming libraries). There is mention of how to fix invalid zip files in that issue:
... it's possible to make a last-minute repair to the zipfile by deleting the bytes from the end of the zipfile. To do this, search backwards from the end for the magic number (see the spec's mention of "central file header signature"), and delete everything that follows the End of Central Directory Record.
But there are no examples of how to implement that fix. So my question is: Given a situation where we have a file buffer with an invalid zip containing a comment that is an invalid length, how would we "search backwards from the end for the magic number, and delete everything that follows the End of Central Directory Record"?