wpackagist icon indicating copy to clipboard operation
wpackagist copied to clipboard

No checksum for packages leads to problems

Open koengabriels opened this issue 2 years ago • 2 comments

I ran into this issue today when preparing my local dev environment, did a composer install and imported a DB dump from the production site, but the site is broken in my local environment. After a lot of debugging I concluded that there must be different codes bases.

Downloaded the plugins and themes folder from production and used PHPStorm to compare it to my local installation. Turns out that version 1.9.3 of wpackagist-plugin/wc-product-table-lite is different in wpackagist than it was when we deployed it on production.

I understand that this happened due to the plugin author messing up but it would save a lot of headaches if there was a checksum that composer could check against. Of course one would still have to solve the issue itself but at least composer can pinpoint the problem immediately.

If someone can point me in the right direction I am willing to try and provide a PR to resolve this issue.

koengabriels avatar Feb 09 '22 11:02 koengabriels

@koengabriels I'd start with the wp plugin verify-checksums command. It seems to call an API to fetch checksums. Example URL: https://downloads.wordpress.org/plugin-checksums/jetpack/10.6.json

However the API seems to only contain the hashes of individual files, not the package file itself. Unfortunately Composer only keeps track of one hash of the whole package zip using shasum in composer.lock.

You could try a different approach and download the resulting zip files in this project and calculate the hash and store it in the WPackagist database. However I think this would open up a similar edge case, because plugin developers can at any point add files to, modify or even delete older tags of their plugins - the WP packaging system will happily repackage the release and WPackagist wouldn't be any wiser, however end users would be in a situation where they can't install their package any more since Composer would probably refuse it since the hash doesn't match any more. This could(?) be preferable though.

If you want to give the above idea a go, you can start by setting up a new command called something like CalculateHashSums and try to download the zip, calculate it and add it to the database.

It'd be super cool to land this functionality in WPackagist but I'm a bit stumped as to how. Sorry I couldn't be of more help!

khromov avatar Feb 11 '22 00:02 khromov

@khromov thanks for the information!

Indeed the problem with plugin developers doing the same thing would still be possible. And end users would not be able to install immediately, but speaking for myself... I rather update the checksum manually after verifying the plugin still works as expected than to risk breaking a production site because the plugin code changed between development and deploy stage :)

In case you will be attending WCEU, I'ld be happy to buy you a beer as a thank you for the quick reply :)

koengabriels avatar Feb 11 '22 18:02 koengabriels