I'm leaving it as "needs patch" because it isn't clear exactly what a committer should do.  

I think the current intent is to make the changes listed in zipfile_???_filename_mismatch_v2.patch (which are not listed as reviewable -- but the changes are indeed sufficiently straightforward that the the files -- if need be -- could be edited by hand as if they were made originally by the committer.)

This change is small enough (warning instead of raise) that a test case is probably not strictly required, but it would be helpful.

test.zip would presumably be useful data for a test case.

There is dispute over whether this would be an enhancement (more generous with what to accept), a bug fix, or a security *regression* because it still allows old vulnerable files to stick around unreplaced (or to hide from a malware scanner), but no longer raises an Exception to get attention.  (warnings are often ignored)




zlib_forward_slash.patch would also be good (and might even be a security fix, by allowing the new versions to be installed), but is not ready to be committed, as 
(A) it repeats the logic inline instead of using the newly defined helper method
(B) it doesn't have a test case (test1.zip should help when creating one)
(C) it has neither a doc change nor an explicit (and dubious) statement that this is just a bug fix and wouldn't need to be listed in the versionchanged. 


There is also a question of how general the filename correction should be, particularly with respect to windows drives and capitalization.  The one in this patch seems to be the minimal change, and is explicitly supported by the zip spec.