Shield Security Automated Scans - Server Settings

General Discussion Security News
18

We’ll be building a file-hashing service ourselves - @invisnet is the person who has done the most thinking and coding about this so far.

What you are doing now sounds right for our official releases.

There are actually two possible release repositories - if the classicpress_version() contains +migration or +nightly then you should look in Releases · ClassyBot/ClassicPress-v1-nightly · GitHub instead.

These versions correspond to the slightly different ClassicPress builds used by the migration plugin to switch sites from WordPress, and nightly release builds, respectively.

I am happy to answer any questions about any of this. In the meantime here are some more technical details that I wrote up previously for another developer:

Here is how you can detect a ClassicPress version number and get the corresponding zipfile for that release:

  • If function_exists( 'classicpress_version' ) , call it to get the ClassicPress version number
  • Look up the full version number in the GitHub API under ClassicPress/ClassicPress-release (example URL). This will catch sites where ClassicPress was installed from scratch or upgraded to a new build after migrating from WordPress.
  • If not found there, look it up in ClassyBot/ClassicPress-nightly (example URL). This will cover sites that were migrated from WordPress to ClassicPress, or people who are running the ClassicPress nightly builds.
  • If the response key assets[0].browser_download_url is set, use it (only true for the +migration.YYYYMMDD builds from the ClassicPress-nightly repository). Otherwise, use the zipball_url response key.
  • If no release data was found, then the site is not using an official build of ClassicPress and this scanner is probably not the right tool to be using.

Any code checking the GitHub API should be able to handle redirects because we may transfer or rename these repositories in the future (especially the nightly builds). Other than that, we’ll always publish our releases to GitHub in this way, so you can rely on this structure for the future.

We have much more planned here, including documentation for people who are interested in verifying our existing chain of trust involving signed git tags, and providing and using a file-hash API ourselves. But that is for another day.

3 Likes