Flag files as optional in Plugin Checksums

[dd32]

When a plugin deletes files from a release, after it's been released, it causes the checksum file to include these files even though they no longer exist.

This is intentional, as the checksums were intended to be used to verify a given file hash against a list of known hashes.

Unfortunately, the checksums are being used as the source-of-truth as to which files should exist. So when a plugin deletes a file, any tool that simply verifies the list of files in the checksum match what's on disk will hit an error when they find the file doesn't exist.

There's several options:

1. Change the format, so that deleted files are no longer in the checksum.
   • Issue with this, is that any plugins installed between release & when the file is deleted, can't verify that the files on disk are unmodified
2. Change the clients, so that they no longer treat the checksum file as the source-of-truth
   • Issue with this one, is that often you want to verify that all the files for a plugin exist on disk, not just that they're updated.
3. Add an extra field to the checksum, that indicates a file has been added/deleted late.
   • Ie. After 2 weeks, file X was removed, and files Y & Z were added.
     • The checksum should pass at the week 3 mark for a plugin installed both before and after the file changes were made.

Currently the format of the file is this:

{
  "plugin": "plugin-slug",
  "version": "1.2.3",
  "source": "https://plugins.svn.wordpress.org/plugin-slug/tags/1.2.3/",
  "zip": "https://downloads.wordpress.org/plugins/plugin-slug.1.2.3.zip",
  "files": {
    "example.css": {
      "md5": "345345345345",
      "sha256": "345345345345"
    },
    "example.js": {
       "md5": [ "34534345345", "567567567" ],
       "sha256": [ "3453453453", "678678678678" ]
    },
.....

In the above format:

• example.css if present must be that md5.
• example.js if present must be ONE of those md5's.

I'm thinking extending it to something like this:

{
  "format": "2",
  "plugin": "plugin-slug",
  "version": "1.2.3",
  "source": "https://plugins.svn.wordpress.org/plugin-slug/tags/1.2.3/",
  "zip": "https://downloads.wordpress.org/plugins/plugin-slug.1.2.3.zip",
  "files": {
    "example.css": {
      "md5": "34345345345",
      "sha256": "3453453453"
    },
    "example.js": {
       "md5": [ "34534345345", "567567567" ],
       "sha256": [ "3453453453", "678678678678" ]
    },
    "notes.txt": {
       "md5": "98098098098",
       "sha256": "98098098098",
       "optional": true,
    },
.....

With this format:
In the above format:

• example.css must be that md5.
• example.js must be ONE of those md5's.
• notes.txt MAY be that md5, or it may not exist, but if it's anything other than those it's invalid.

I've added the format field there to flag that this the clients can expect that behaviour, but we won't be able to alter existing ones (except in special cases) and so it would only really be able to be trusted for plugins released after the implementation date.

[dd32]

Initial ticket had a typo in the format, the arrays are within the checksum-type, not within the file-level handler.. fixed that up..

[tellyworth]

"optional" isn't entirely clear as to its meaning.

As an alternative to "optional": true, what about "last_version": "1.2.3"? Or "present_in_versions": "1.0-1.2.3".

Other boolean alternatives: "current": false, "active": false, "deprecated": true.

[dd32]

Replying to tellyworth:

As an alternative to "optional": true, what about "last_version": "1.2.3"? Or "present_in_versions": "1.0-1.2.3".

Checksum files are versioned, so it's In this specific version of the plugin-slug 1.2.3, file XYZ.ext should be one of these hash(es): ..... OR not present.

Other boolean alternatives: "current": false, "active": false, "deprecated": true.

With the above in mind, these make less sense :)