[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 dd32):

 Replying to [comment:6 schlessera]:
 > Some observations on
 [https://meta.trac.wordpress.org/ticket/3192?cnum_edit=6#comment:2 #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).
 Correct

 > 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.

 That is what I outlined in Comment:2 above, and as a result, the POC
 although it's in the ZIP generation class, *does not link checksums to a
 ZIP file* - they may by coincidence match, but you cannot assume that
 `plugin.2.0.zip` will have checksums in the `2.0` file (It might be in
 `2.0.1` instead, because the ZIP is named incorrectly).

 > 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?

 We could retroactively calculate them, but I don't think we should bother,
 it's not worth anyones time to do so.
 We can create the checksums for previous tagged releases, which will cover
 the vast majority of plugins. Those who made multiple releases on a tag or
 from trunk would only have checksums for the latest version of the files.
 In other words, checksums going forward will be useful, but historical
 checksums for a plugin which had 50 releases from `/trunk/` in 2009 won't
 be (Only the latest release that was made from /trunk/ would be).

 > '''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.

 Here's another test checksum file, which covers a file being added in a
 later version update, and the main plugin file being updated.
 https://downloads.wordpress.org/plugins/test-
 plugin-3.1.1.2-20160302.checksums.json
 If you wish, I can add that to the regular generation & provide you commit
 to it to add


 > '''C. Database'''

 We won't be investigating anything regarding this at this time.

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