If I zip a plugin folder using MacOS right-click Compress command in the contextual menu, those archives are no longer accepted when using upload plugin ( WordPress 6.4.3 ). It returns "Incompatible Archive". This has worked up until now. The issue is related to the recent security updates for the plugin and theme uploader.
If I create a zip on the command line of the same folder that works correctly.
In short: The ZIPARCHIVE::CHECKCONS flag causes checks to use a "pedantic" mode, which Apple's Archive too fails.
(For some internals from an Apple dev, see https://wordpress.org/support/topic/macos-zip-files-made-with-the-built-in-archive-utility-arent-accepted/#post-15815401 ).
This has previously affected WordPress (#12637) and WP-CLI (https://github.com/wp-cli/extension-command/issues/362).
It looks like libzip has a solution already (https://github.com/nih-at/libzip/issues/341 and https://github.com/nih-at/libzip/commit/b3e3b19e2e4b7d4651d01148f123129429ecc69b) but that will probably still need to make its way to servers...
One solution for Core could be to just repeat the call to $archive->open( $file['file'] ) (but without the ZIPARCHIVE::CHECKCONS flag) or to try a fallback check with PclZip on failure as well (and not just if the ZipArchive class is not available).
Lowering the severity since there is currently a workaround on both the zip creation side ( use the command line) and the individual site side ( add_filter( 'unzip_file_use_ziparchive', '_return_false' ); ).
creating your zip file manually works.
(using terminal on MacOS, instead of right-click > compress in finder)
zip -vr theme.zip your_theme/
see: https://superuser.com/q/505034/415143
p.s. use the zip command, not ditto (since that is the same as compress in finder)
The workaround here where impacted plugin authors can STOP using the MacOS UI for generating ZIPs and START using the command line to do so. Like below
zip -r webtoffee-product-feed.zip webtoffee-product-feed
