Opened 4 years ago
Closed 23 months ago
#51714 closed defect (bug) (invalid)
Theme MD5 checksums for 5.5.3 alpha do not match WordPress.org API checksums.
Reported by: | datainterlock | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 5.5.3 |
Component: | Upgrade/Install | Keywords: | close |
Focuses: | Cc: |
Description
Been trying to figure this out for a few days days and finally solved it.
I'm working on and MD5 checksum scanner plugin. One of my sites got the famous alpha 5.5.3 install with all the associated themes. My scanner successfully identified these files but instead of recognizing them as simply new files with correct checksums, it recognized them as all having different checksums from the files on the WP.org site.
Here's how my plugin works for themes since there is no official API checksums. It physically downloads the theme to the server, unzips it to a temp directory and gets the MD5 checksums from all the files it finds. It then compares those checksums to the currently installed theme's checksums. If the files haven't been changed, the checksums match.
In the case of the alpha install, every single theme file had a different checksum which should not have occurred if they came from the WP.org theme repository. So why were they different?
The alpha update came from a Windows server but, the WordPress API is on a Linux server. When the update downloaded all those themes, the MD5 checksums were an exact match for files that had been first downloaded to a Windows machine and FTP'd via ASCII file transfer to a Linux machine. The Windows CR+LF get converted to the Linux NL. The WordPress API server is on a Linux machine because if my plugin downloads a theme, the checksums are exactly the same as if you had installed that theme via the dashboard. That's because there's no CR+LF to be converted.
I verified all of this by downloading the twenty eleven theme to my Windows machine and FTP'ing the files via ASCII to my server. My MD5 scanner found all of the theme files to have inaccurate MD5's as expected which exactly matched the alpha update checksums. I then uninstalled the twenty eleven theme via the dashboard and reinstalled via Appearance/Themes/Add New. The checksums all matched.
Checksums for an example file: wp-content/themes/twentyeleven/colors/dark.css
Download URL: https://downloads.wordpress.org/theme/twentyeleven.3.5.zip
Installed via alpha update : MD5: aef2880581a7226882780ffee6f8566e
Uploaded via FTP from a Windows machine: MD5: aef2880581a7226882780ffee6f8566e
Downloaded directly to a Linux machine and unzipped: MD5 : d45d493d402d5712ff78878a1d34b6a2
Installed via dashboard : MD5 : d45d493d402d5712ff78878a1d34b6a2
Change History (4)
#2
@
4 years ago
No, this was installed on a Linux server which caused the discrepancies because they all had Windows MD5's. Normal updates have not yet caused any discrepancies with bundled themes but they haven't installed 10 year old themes either.
I'm not sure to whom or where to point this out but I'm simply suggesting that even for the alpha updates that get pushed out, someone, somewhere should consider being consistent with whether they're pushed via a Windows or a Linux server so that MD5's remain consistent with downloads.wordpress.org.
Hi there, welcome to WordPress Trac! Thanks for the ticket.
This post provides some technical details on 5.5.2 and 5.5.3 releases:
https://make.wordpress.org/core/2020/10/30/wordpress-5-5-3-release-some-technical-details/
If the update was installed on Windows server, the EOL character differences would indeed explain the checksum discrepancy. However, if you compare the
wordpress-5.5.2.zip
andwordpress-5.5.3.zip
archives of the final releases, you'll find that the bundled themes are exactly the same.So it does not look like there are any actionable items for WordPress core here, other than to make sure that an accidental update to an alpha version does not happen again.