The following perl modules have been updated:
The following modules have been updated:
Today we received a security notice:
Affected package: wordpress-2.8.2,1
Type of problem: wordpress — remote admin password reset vulnerability.
Description:
WordPress reports:A specially crafted URL could be requested that would allow an attacker to bypass a security check to verify a user requested a password reset. As a result, the first account without a key in the database (usually the admin account) would have its password reset and a new password would be emailed to the account owner.
References:
- URL: <http://wordpress.org/development/2009/08/2-8-4-security-release/>
- URL: <http://www.milw0rm.com/exploits/9410>
Affects:
- wordpress <2.8.4,1
- de-wordpress <2.8.4
- wordpress-mu <2.8.4a
Our installations of WordPress and WordPress-MU have been updated.
In addition, a review of our logs revealed several hack attempts using admin_topic_action_logging.php. Apparently some IBM systems are vulnerable to this exploit. The offending IPs have been banned from our server.
The following packages were updated:
There are a number of minor updates to some X11 related modules that currently fail to build, mainly due to the lack of gconf2-2.4 in the ports distribution. Even those modules that still include gconf2.2 fail to build correctly as they fail to recognize that gconf2.2 is current and attempt to needlessly rebuild and install the module.
This seems to be a common feature in the X11 distributions, not enough attention is paid to build dependencies, as anyone who builds and maintains X11 can attest.
My main interest in X11 related tools stems from the MVC model for web design. While this model is appealing, use of the model is cumbersome and it’s dependence on Java presents noticeable performance problems.
None of the X11 related tools are currently in production use.
The following perl modules were updated:
The following modules have been updated:
As I was running tests on all of the Wordpress enabled websites I maintain, to verify that the recent PHP & WordPress upgrades were working I ran across a puzzling problem. One of my website’s blog displayed nothing but a white screen. After pouring over every log file I could find I discovered there was nothing to find. The only error message generated by these white screens was an httpd error 500!
So I went off to google foo to see what I could find. Turns out, this seems to be quite the problem in the WordPress world. It also seems that there are many, many theories and proposed solutions to what is called the “WordPress Blank Screen of Death“.
While I did foo some good advise, most of it I had already explored in several hours of debug work. The most likely cause, since this problem reared it’s ugly head after my PHP upgrades, was a misbehaving plugin. But which one? And how do you disable a plugin when you can’t even get to your dashboard?
The trick was found by examining the database(s). In the options table there is a tuple enumerating the plugins in use. After verifying that this was the sole definition, clearing out the plugin attribute in the tuple cleared the problem.
And after a bit of testing I found the offending plugin:
Fatal error: Cannot redeclare widget_email_init() (previously declared in /usr/local/www/data/wordpress/wp-content/plugins/wp-email/wp-email.php:1400) in /usr/local/www/data/wordpress/wp-content/plugins/wp-email/wp-email-widget.php on line 102
Apparently this plugin was discontinued in WP-EMail 2.5. You will need to completely remove the plugin before upgrading to get rid of the php file for the widget.
After reviewing the updates of some of Lester’s other plugins it appears that his updates are all implemented differently. You will need to completely review any and all of these plugins to ensure that the old versions are deleted.
And finally a word on WordPress best practices upgrade procedures which call for de-activating all plugins prior to the upgrade. If you are running multiple sites, this is an unwieldy procedure. It is far easier to make sure all plugins have been upgraded to their latest versions and then take the failures up on a case by case basis.
It would be a great help, if when upgrades are detected during subsequent accesses to each website, that not only a database update is preformed, but a check or a reinstall is run on each of the plugins deployed for the site. This notion of a “Wordpress Blank Screen of Death” is comical at best.
The recent PHP update left the extensions.ini file sorted. Unfortunately some of the extensions contain dependencies that result in undeclared forward references. The .ini file was reordered to accommodate the build deficiency.
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/20060613/mysqli.so’ – /\
usr/local/lib/php/20060613/mysqli.so: Undefined symbol “spl_ce_RuntimeException” in Unknown on line 0
PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/20060613/soap.so’ – /us\
r/local/lib/php/20060613/soap.so: Undefined symbol “ps_globals” in Unknown on line 0
In addition, jpeg-7 was rebuilt.
PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/20060613/gd.so’ – Share\
d object "libjpeg.so.9" not found, required by "gd.so" in Unknown on line 0
The following perl modules were updated:
A review of our server log files revealed a version mismatch. The error log entry fixed by rebuilding mod_python and restarting Apache was:
[Sun Aug 02 20:03:39 2009] [error] python_init: Python version mismatch, expected ‘2.5.2′, found ‘2.5.4′.
