[wp-meta] [Making WordPress.org] #3192: Provide an API endpoint to fetch plugin checksums

[Making WordPress.org]

#3192: Provide an API endpoint to fetch plugin checksums
------------------------------+-----------------------
 Reporter:  schlessera        |       Owner:  dd32
     Type:  enhancement       |      Status:  accepted
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:                    |
------------------------------+-----------------------

Comment (by schlessera):

 Some observations on #2 above:

 '''A. Multiple checksums for a same file'''

 Given the way ZIPs are being built, I suppose that different downloads of
 a ZIP of a given version name could result in different files as the
 actual content of the ZIP, depending on when the ZIP was built and
 downloaded (i.e. what SVN revision it was built at). To reliably check the
 files on existing WordPress installations would mean that we need to have
 '''all possible checksums''' for any given file at a named version, not
 only the latest for that named version. So, if a ZIP is being generated,
 and the checksum file already exists, the newly calculated checksums need
 to be added to the checksums file, if they are different from the ones
 that are already included.

 If I understand correctly, the provided POC already does this. However, I
 wonder how we can retroactively calculate these multiple checksums for all
 existing versions. Does it make sense to merge all revisions that are
 tagged with a same version, or can some of them be excluded through some
 existing data?

 '''B. Test plugin'''

 The exploit plugin is great for making sure the calculated hashes are
 correct, but it seems to be very simple and properly versioned. Can we add
 one other plugin, that is known to include as many edge cases as possible?
 A plugin that has multiple released versions with a same named version
 tag, for example, to test the merging of multiple checksums for a same
 file.

 '''C. Database'''

 Regarding the database, I agree that an SQL database is not a good fit,
 but actually using SQL was never explicitly mentioned. If we want to
 examine the use of a database, we should rather examine the use of a NoSQL
 database like Redis, MongoDB, or Cassandra. They provide similar benefits
 than a file-based approach, but with added optimizations and integrity
 checks. They can also be synced more reliably across multiple servers.

 However, I suppose that these are not part of the existing infrastructure,
 so might not even be an option at all.

--
Ticket URL: <https://meta.trac.wordpress.org/ticket/3192#comment:6>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org