Actually our normal procedure currently (this will change a bit after the migration to mercurial) is a patch against the py3k branch, and the committer will do the backport to the other active branches.  If the 2.7 code is very different, a separate 2.7 patch is sometimes helpful.  In this case it looks like a patch that applies to py3k is enough.

Alan hasn't spoken up yet, and he's listed as maintainer.  If he doesn't speak up someone else will hopefully make a decision before the end of the beta period for 3.2.  I'm bumping up the priority of this issue because I think not being able to handle commonly produced archives that other zip tools can handle is a relatively serious defect.

My own opinion is that truncation if the extra data doesn't look like a comment makes the most sense.  But absent an opinion from Alan I think I'd be guided by whatever other zip tools do in this case.  Kevin, am I correct in guessing that that is truncation?

Ned is definitely correct that absence of a test case is something that can delay getting a patch applied.  If a patch includes a unit test, a committer can often do a quick review-and-apply, while absent a unit test the committer would first need to write one, and therefore will often move on to some other, easier to process issue :)  In this case it seems to me that the unit test will only differ in one detail depending on the fix chosen, so it may be worth writing it even before a final decision is made, if you are willing.