[wp-hackers] Richer metadata for plugin versions

[Mika A Epstein]

tl;dr: I do like the idea, but it'd be hit-and-miss as much as the Upgrade Notice.

Given that there isn't the same oversight and scrutiny with a plugin as there is with themes (once you're in the repo, we trust you until you show up on our sneaky lists of doing_it_evil() or someone reports you), I think it's a great idea that would be nigh impossible to enforce. 

Part of the reason the current notice isn't used all the time is ... we don't make you. The only time we really can is when we close a plugin due to a security issue, and that's because we do review it before it's re-released. I'm willing to put money down that we only close half the security-issue plugins, and the rest are resolved by the good guys who get that secunia email and dive in right away. Without the ability to enforce that change, it's not very useful, alas. We can't even get everyone to update the 'Compatible up to...' tag as it stands, and Zoidberg knows how many people think that's the Holy Grail of determinations when picking a plugin. (Zoot put up the false grail light!)

This is why I always suggest you run a separate, clean-ish, install somewhere on the same server, and keep all the plugins you use there. Test the upgrades before you upgrade the real boxes. :)

On Jul 11, 2012, at 1:57 AM, David Anderson <david at wordshell.net> wrote:

> 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
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers