[wp-hackers] Richer metadata for plugin versions

[David Anderson]

Hi,

This is my first post, so a brief introduction: I am David Anderson, a 
Baptist missionary working amongst the urban poor in Eldoret, a large 
town in Kenya (http://david.dw-perspective.org.uk). I am also the author 
WordShell (http://wordshell.net), a tool I developed to help me maintain 
many WordPress websites from the command-line, and since it saved me 
huge amounts of time+money I thought it would be interesting to others 
and decided to try to commercialise (it is both GPL and commercial 
software). I also maintain the free UpdraftPlus back-up plugin 
(http://wordpress.org/extend/plugins/updraftplus).

One challenge when maintaining a lot of websites is, to know which 
plugins need to be updated immediately (e.g. a zero-day security hole), 
and which not (perhaps on your client's website it is better to wait a 
week - some plugin authors upload code with fatal errors in, or they add 
new bugs and fix them 2 hours later, etc.).

A plugin's readme.txt file can contain an "Upgrade Notice", which can be 
processed by a human to attempt to make a decision. However there is no 
standardised format for this, and most plugin authors ignore it.

Am I right in this assessment of the situation?

If so, then it is something that makes it hard for maintainers to make 
intelligent decisions, and impossible to automate or semi-automate them.

Having been chewing over this for the last couple of months, I have this 
proposal: Add a tag to readme.txt, "Latest security update: ". The 
contents of the tag would be the most recent version number that fixed a 
security flaw.
e.g. Latest security update: 0.1.7

Then both humans and robots can know that if you are running a version 
less than 0.1.7, then they should update.

This scheme could be made more sophisticated. For example, perhaps you 
are running 0.1.5, and the specific security hole did not exist until 
0.1.6. Therefore you do not need to update. So a more sophisticated 
scheme would be instead to indicate vulnerable versions.
e.g. Imagine that 0.1.4 has the security version, but that also the 
whole 0.0.x series had a different hole, and 0.1.1 up to 0.1.3.
Insecure versions: 0.0.*, 0.1.1-0.1.3

If there was a standardised format, involving wildcards (*) and ranges 
(0.1.1 - 0.1.3) and comma/space separation then that could still be 
easily both human and machine parsable.

As a final step, for wordpress.org-hosted plugins, this data ought to be 
exposed through the API so that machines can extract it without needing 
to download the whole plugin. In combination with the already-exposed 
version compatibility data, you could then programmatically know that 
"my present version of the plugin is compatible with my present 
WordPress version and is secure".

Of course, many plugin authors might not deploy this tag. But at least 
for those that do, those maintaining WP websites that are meant to be 
maintained in a conservative manner could reduce their risks, by knowing 
that "my present plugin version is not insecure; I do not need to 
update" for some plugins at least.

So...

- What do people think; would this or a similar addition to readme.txt 
be desirable?
- Are either of the schemes above suitable?
- What would be the way forward to add it? I looked at the descriptions 
of mailing lists, and though this seemed the most suitable one 
(apologies if I blundered), I could not work out who I really needed to 
talk to.

Many thanks,
David

-- 
WordShell - WordPress fast from the CLI - www.wordshell.net