Plugin Status Service

Source: https://github.com/ossreleasefeed/plugin-status-service

Elevator Pitch

Rewrite plugins.m.o, leveraging the current data but expose the raw JSON data so that plugin developers and the general community can be part of the process of keeping plugin version data up to date. This will be achieved by making use of tools/services that users are already familiar with, such as via pull requests on Github and, should have a hook to enable plugin vendors to make this part of their automated release procedure again, using familiar tools such as git (edit, add, commit, push) and pull requests using the Github API.

Use Cases

Community

Scenario 1

Community member discovers a new release of a particular plugin.

The user either:

1. Checks their current plugin, prior to updating, and discovers that mozilla.org/plugincheck still marks it as up to date.
2. Updates their plugin and discovers that mozilla.org/plugincheck marks it as newer.

Both these scenarios indicate that the plugin status service does not have this new information.

Community member heads to Github, updates the content of the relevant plugin and opens a pull request. Maintainers of the origin are notified and after verification of the data, the requests is merged and change is pushed via CI to production in a matter of minutes.

Scenario 2

User navigates to mozilla.org/plugincheck to determine whether all of their plugins are still up to date. The service labels some of their plugins as unknown and marks one (or more) as newer. Below each group i.e. 'newer' and 'unknown' there is a link stating:

1. For unknown plugins - 'Suggest a plugin to track'
2. For plugins marked as newer - 'Suggest a new version'

Both of these will link to the main repository' issues tracker with some base information about the unknown or newer plugin(s). Again, maintainers are notified and can take action.

NOTE: This is much the same as issues are done for Shumway using the Shumway SWF Archive test platform.

Plugin Vendors

Vendor is about to release a new, updated, security release of their plugin.

Vendor opens the relevant JSON file either locally or via their fork on Github and edits/adds the relevant information. Next, as part of their automated release procedure, they have the following:

    git add .
    git commit -m 'Short blurb about release, perhaps even just new version number'
    git push vendor plugin_versionnumber

Uses Github PR API [1] to initiate a pull requests (as part of the above automated process). Maintainers of the origin are notified and after verification of the data, the requests is merged and change is pushed via CI to production in a matter of minutes.

Data Structure

The data structure requirement is as follows:

• We need to store information about the following releases:
  • The latest release
  • The latest safe release i.e. There might be a new release of the plugin but, the version before is still safe and does not suffer from vulnerabilities. For example having Java 7u51 even though Java 8 has been released.
  • Vulnerable

Other statuses such as newer and unknown will be determined programmatically by either the absence of the plugin from the maintained data or, the fact that the version number for a known plugin is greater than what we have in the database.

There also exists a need, which is currently not satisfied, to track and support ESR releases for various plugins based on OS level. Especially for Flash and Java this is increasingly important in order to offer accurate reporting of a plugin's status. With that in mind, releases should be tracked against the operating system version up to a patch level granularity using semantic versioning.

Database

As most all processing of the data happens on the client, the requirements from a database perspective are pretty low and only a few requirements are really needed to satisfy this dependency.

1. The database should support the ability to import, export and query JSON. Querying directly against JSON is not a requirement as long as the first two are well supported.
2. Each plugin will be a self contained JSON document and updating the database from these JSON documents should be supported. See Flash player JSON for an example.
3. Queries against the data will be limited to a few predefined queries.

• The most run query will be to get all plugins for a specific operating system.
• Query to update data based on a JSON document as described in point 2 above.

On a schedule, ~once in a fortnight, a process will be run to extract all the data from the database, format the data and publish the result as a JSON file back to the plugin status service repository. View a sample file.

Development Depencies

• Nodejs
• MongoDB