[wp-meta] [Making WordPress.org] #6275: Flag files as optional in Plugin Checksums

[Making WordPress.org]

#6275: Flag files as optional in Plugin Checksums
------------------------------+--------------------
 Reporter:  dd32              |      Owner:  (none)
     Type:  feature request   |     Status:  new
 Priority:  normal            |  Milestone:
Component:  Plugin Directory  |   Keywords:
------------------------------+--------------------
 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",
           "sha256": "3453453453"
         },
         {
           "md5": "567567567",
           "sha256": "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": "34534534534",
           "sha256": "345345345"
         },
         {
           "md5": "78978789",
           "sha256": "7897897897"
         }
     ],
     "notes.txt": [
         {
           "md5": "456456",
           "sha256": "45645645"
         },
         {
           "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.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/6275>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org