[wp-hackers] Richer metadata for plugin versions
david at wordshell.net
Thu Jul 12 05:30:09 UTC 2012
> 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??
WordShell - WordPress fast from the CLI - www.wordshell.net
More information about the wp-hackers