Update Plugin Submission Page to check for zips

[Ipstenu]

Validate submission is a zip that can be opened.

If the submission isn't a zip, we cannot accept it or review it.

[dd32]

This seems to be an odd request - As a plugin can't get passed the initial submission steps if it's not a ZIP.

If a plugin was uploaded that's not a ZIP, it wouldn't extract and therefor would trigger the Error: The plugin has no name. errors.

The upload form also requires a .zip extension, which yes can be bypassed to upload a .php file, but that fails to be parsed by the uploader, triggering the The plugin has no name error again.

[Ipstenu]

That's what's weird, but we get broken zips on upload that won't properly unzip.

End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.

I'm trying to find the submission that prompted this, and I know it's NOT the person who kept complaining that his password protected zip failed.

[dd32]

That's what's weird, but we get broken zips on upload that won't properly unzip.

Interesting.. I'm guessing these are archives that aren't actually ZIPs, but are another format that the linux unzip utility can decode - or potentially the ZIP is corrupted like you say, and the library we're using is unzipping it but throwing an error we're not catching (This looks likely).

Looking at past plugin uploads, I can see a bunch of plugins are including some.. invalid filenames, such as banners and icons with non-ascii characters in the filenames, eg:

plugin-name/assets/icon-256#U00d7256.png:  mismatching "local" filename (plugin-name/assets/icon-256+�256.png),
         continuing with "central" filename version

I've found at least half a dozen plugin uploads since December that have that issue.

I've been unable to find any .zips that fail to extract though, at least according to unzip -t $zip.

Looking through the uploads, based on file utility.. everything seems to be ZIPs, but two are a newer version than the rest.. These seem like Zip64's

$ find . -name '*.zip' | xargs -I% file % | cut -d: -f2 | sort | uniq -c
    591  Zip archive data, at least v1.0 to extract
   1273  Zip archive data, at least v2.0 to extract
      2  Zip archive data, at least v4.5 to extract

I'll DM you examples of both to see if either of those are the issue.

[Ipstenu]

FWIW I unzip on my Mac using UnZip

UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

Assets being misnamed errors on my mac, but in a way I know it's only the assets. But yeah, it's 100% a problem with people not reading and putting in the multiplication X. Sometimes I think we should allow both, and others I think "people need to read more carefully and slow down, it's juts a plugin, not brain rocketry"

It's incredibly rare that a zip-as-submitted has this problem, and more often the resubmits via email do, but I will look for the one that prompted this ticket.

[dd32]

Closing this as worksforme for now.