wp security and upgrading

[Jake McMurchie-2]

Hello wp-hackers. I'm not sure if this list is the right place for this
question so apologies if this is off-topic (and will be grateful for
appropriate redirection)...
In the past I have always advised clients to upgrade Wordpress on the basis
that upgrades usually include fixes for security vulnerabilities and this
will counter-balance any work required to upgrade themes, plugins and other
(frequently bespoke) customisations. However, I have a sense that this
balance has shifted - no security vulnerabilities have been made public with
2.7/2.7.1 (that I'm aware of) and 2.8 has not been advertised as a required
upgrade for security purposes. If this is correct then full credit and
congratulations to the WP team :-)

Given that there's a time/cost implication for upgrading, that the new
features of a new version may not be required, and that additional work may
be required to adapt customisations to changes in the codebase and database,
is it reasonable to say that upgrading (at least from 2.7/2.7.1) is down to
client preferences, especially given the many other steps one could take to
improve security besides keeping the WP version up to date?

Many thanks in advance.

Jake
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Ozh]

> is it reasonable to say that upgrading (at least from 2.7/2.7.1) is down
to
> client preferences, especially given the many other steps one could take
to
> improve security besides keeping the WP version up to date?

I would still advise client to always upgrade.

For instance, after 2.8.1 comes out, if there's a new exploit around that
comes up and leads to a 2.8.2, I think the average Joe would be more
scared with going straight from 2.7 to 2.8.2 than simply upgrading as new
versions come out.

Also, a lot of people think you have to upgrade to every version one after
the other, ie if you want to go from 2.7 to 2.8.2, you have to upgrade to
2.7.1, then 2.8, then 2.81, then 2.82, imagine how cumbersome that is for
those people.

Finally, the problem I see with letting this up to the client's decision
is, how will they react if something breaks? For instance, most themes
using ui-tabs broke with 2.8 because of a change in jQuery UI. Will the
client assume it's because of something in WP? of something related to
your previous work with them?

When the user interface doesnt radically change as it did with 2.5, I
would always suggest to keep all things up to date.

Ozh


_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Lynne Pope]

2009/6/30 Jake McMurchie <jake.mcmurchie@...>

> ...... no security vulnerabilities have been made public with
> 2.7/2.7.1 (that I'm aware of) and 2.8 has not been advertised as a required
> upgrade for security purposes.


While there hasn't been anything (at least in public) about vulnerabilities,
2.8 includes security improvements, such as these...
 - Refactor filters to avoid potential XSS attacks
 - Deprecate wp_specialchars() in favor of esc_html(). Encode quotes for
esc_html() as in esc_attr(), to improve plugin
security<http://codex.wordpress.org/Data_Validation>(ref. Development
Updates <http://wpdevel.wordpress.com/tag/escaping/>)

(From: http://codex.wordpress.org/Version_2.8)

So, from the point of enhanced security its a worthwhile upgrade.
Performance is better too, although depending on the site this may not be
very noticeable to clients.

I have the same dilemma and have people still on 2.6.5, some of whom are
sticking with that. If it helps, this is the criteria I use to decide
whether to recommend an upgrade.

1. If the server is secure and plugins have been checked for security, and
the user does not want threaded comments - leave as is.
2. If the user adds their own plugins - recommend upgrade.
3. If the site is using plugins that have not yet been updated for 2.8, then
wait.

Lynne
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Otto-19]

Upgrades are always recommended, but I have detected a sense of
urgency lately that I would not say is there. My advice is:

1. Upgrades should always be performed, but if a site is critical to
operations, then a proper test should be undertaken first. Set up a
similar test site with WordPress and all the plugins/theme you're
using, then upgrade it and test to make sure everything works first.
Don't upgrade live without testing unless you're comfortable fixing
issues in real time. and really, they should already have a decent
test site set up (perhaps in a subdirectory), so that they can test
changes before implementing them live.

2. If a site is critical and there's no immediate security threat,
wait a week or two. Plugins frequently don't get updated before a
release, wait until the plugins have been checked first, upgrade them,
then upgrade the site.

3. Advice your clients to read the changelogs, or have somebody
summarize them for them before an upgrade. This way, they know what
changes to expect.

-Otto



On Mon, Jun 29, 2009 at 7:49 AM, Jake
McMurchie<jake.mcmurchie@...> wrote:

> Hello wp-hackers. I'm not sure if this list is the right place for this
> question so apologies if this is off-topic (and will be grateful for
> appropriate redirection)...
> In the past I have always advised clients to upgrade Wordpress on the basis
> that upgrades usually include fixes for security vulnerabilities and this
> will counter-balance any work required to upgrade themes, plugins and other
> (frequently bespoke) customisations. However, I have a sense that this
> balance has shifted - no security vulnerabilities have been made public with
> 2.7/2.7.1 (that I'm aware of) and 2.8 has not been advertised as a required
> upgrade for security purposes. If this is correct then full credit and
> congratulations to the WP team :-)
>
> Given that there's a time/cost implication for upgrading, that the new
> features of a new version may not be required, and that additional work may
> be required to adapt customisations to changes in the codebase and database,
> is it reasonable to say that upgrading (at least from 2.7/2.7.1) is down to
> client preferences, especially given the many other steps one could take to
> improve security besides keeping the WP version up to date?
>
> Many thanks in advance.
>
> Jake
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Heiko Rabe]

Hi,

could somebody please explain, what this should be?

File:    wp-admin/includes/continents-cities.php

content snippet:

<?php

/* Continent and city translations for timezone selection.
 * This file is not included anywhere. It exists solely for use by xgettext.
 */

__('Africa', 'continents-cities');
__('Abidjan', 'continents-cities');
__('Accra', 'continents-cities');
__('Addis Ababa', 'continents-cities');
__('Algiers', 'continents-cities');
__('Asmara', 'continents-cities');
__('Asmera', 'continents-cities');
__('Bamako', 'continents-cities');
__('Bangui', 'continents-cities');
__('Banjul', 'continents-cities');

..... many more ....


Why did it use a different text domain than WordPress Core itself ?
Even if this is would be contained in main WordPress *.mo file, it
doesn't get translated because this text domain doesn't exists.
Furthermore the remark text states, that it is nowhere included, so why
we are able to tranlate such things if they never been accessed
somewhere but occupy 486 entries at *.mo generation/translation ?

regards

Heiko Rabe
(www.code-styling.de)
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Peter Westwood]

On 29 Jun 2009, at 22:04, Heiko Rabe wrote:
>
> Why did it use a different text domain than WordPress Core itself ?

So as to make translation optional without filling up the main file  
and making it difficult to tell if you had translated all the strings.

>
> Even if this is would be contained in main WordPress *.mo file, it  
> doesn't get translated because this text domain doesn't exists.
> Furthermore the remark text states, that it is nowhere included, so  
> why we are able to tranlate such things if they never been accessed  
> somewhere but occupy 486 entries at *.mo generation/translation ?

The strings are used elsewhere as they come from php function calls  
but listed there so the translation tool can pick them up.

For more info read the wp-polyglots mailing list archives.

http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003430.html

This is probably a more appropriate topic for that list.

westi
--
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Eric Marden-2]

Heiko Rabe,

Please start a new thread for a new topic. Changing the subject line  
isn't enough.

-e

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers