[wp-hackers] Richer metadata for plugin versions
david at wordshell.net
Wed Jul 11 06:57:00 UTC 2012
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
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
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.
- What do people think; would this or a similar addition to readme.txt
- 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
WordShell - WordPress fast from the CLI - www.wordshell.net
More information about the wp-hackers