[wp-hackers] Richer metadata for plugin versions

[David Anderson]

> sounds nice..
>
> but, isn't this what the upgrade notice tag is for?
>
In part, but mainly not. The "upgrade notice" is an arbitrary free-form 
text field. It has no structure and cannot be machine-parsed. It 
requires a human being to interpret its meaning. It is not like the 
existing compatibility metadata which is structured and parsable.

I was proposing machine-parsable, fixed-format meta data which can be 
used to programmatically resolve the question, "does this version of the 
plugin have known security problems?", just as we presently have 
meta-data which can deterministically resolve the question "is this 
version of the plugin compatible with my version of WordPress?".

> if devs can't be forced to use the upgrade notice tag, what's going to
> make the security tag any different?
If the tag is optional, then that provides an opportunity for plugin 
authors to differentiate their offerings by providing the data. 
Possession of this tag will be one more indicator of whether you're 
using a quality plugin or not. Failure to include it will be a data 
point that the plugin author sees security as a second-class concern. 
That's a useful data point for users evaluating plugins. Win-win.

> and if this is made compulsory, what's going to stop devs from just
> listing all versions under the secure tag?
>
Nothing, but so what? All meta data fields can be abused, but that 
doesn't mean they are all undesirable. If a dev fixes a security problem 
in a new release, and yet for some weird reason decides to list the 
previous version as secure, then that's also valuable data that the 
community can respond to - you then know that the dev treats security as 
a PR exercise instead of taking it seriously. People can blog that fact.

> also, most users don't usually install "old" versions unless they need
> one to be compatible with their installed wp version for server
> compatibility reasons (php4)
Adding new meta-data allows the user to make more informed decisions. If 
the user makes bad decisions, that is up to him. The intended purpose of 
the meta-data I was suggesting was not to advise the user "don't 
update". Personally I had in mind that it would give me a better idea of 
how quickly I need to think about updating. (Can my site be broken into 
right now? Should I test the new version for 5 minutes before deploying? 
Or is it a bunch of new features I don't urgently need, and I can be 
more leisurely in my testing?). Meta-data doesn't force anyone into any 
decisions; it better informs them for better decisions.
>
> So, Otto's point is, if a plugin has the following versions: 2.1, 2.2,
> 2.3, 2.4  and version 2.3 is marked as a security update but the latest
> version 2.4 isn't, then that's sort of like saying "it's okay not to
> update to v2.4"
No, that's confusing between meta-data and the interpretation of 
meta-data. The data point "this release is a security release" would 
mean "update sooner rather than later" to most sane users, but the data 
point "this release is not a security release" does not imply "don't 
bother installing it" - that's an over-interpretation.

This issue is one that most architects of update systems have faced. I 
use Fedora; the XML metadata for the package repositories now include 
security meta-data. I can delegate my update decisions to a machine, by 
adding --security to my update command line; and in Africa, where 
all-you-can-eat Internet is expensive (I'm on pay as you go), that's a 
valid concern. I don't want to pay $5 for every update available to then 
find it broke my machine; I want to be more conservative.
If you use Windows update, it classifies updates as to whether they are 
security or not. There is a trade off of risks between the time taken to 
update and the need to evaluate the quality of updates. Enriching the 
metadata will improve the lives of WP admins by giving them higher 
quality data to base this decision upon.

Anyway... am I going about this the right way? Who do I actually need to 
persuade? I'm thinking of putting together a web-page of pros-and-cons, 
FAQs; but who would I need to present it to anyway??

David

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