http://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor_id=2337

So we have these missing CVEs (at least):
CVE-2011-3130, CVE-2011-3129,CVE-2011-3128, CVE-2011-3127, CVE-2011-3126, CVE-2011-3125, CVE-2011-3122, CVE-2012-0287

URL: (none) => http://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor_id=2337
Component: RPM Packages => Security
Assignee: bugsquad => mageia
Summary: wordpress is newer in MDV 2010.2 (contrib) updates than Mageia 1 => missing security updates: wordpress (CVE-2011-3130 CVE-2011-3129 CVE-2011-3128 CVE-2011-3127 CVE-2011-3126 CVE-2011-3125 CVE-2011-3122 CVE-2012-0287 )

WIP, thanks.

Status: NEW => ASSIGNED

wordpress-3.3.1-1.1.mga1 is now available in updates_testing to fix CVE and upgrade from Mandriva. 
As API changed, I put the last version of WP to be sure that plugins and themes will be compatible.
Please test it before I opened an update request.

Hardware: i586 => All
Assignee: mageia => qa-bugs

Advisory:
This update upgrade wordpress package to permit upgrade from Mandriva 2010.2 and fix CVE-2011-3130, CVE-2011-3129,CVE-2011-3128, CVE-2011-3127, CVE-2011-3126,
CVE-2011-3125, CVE-2011-3122, CVE-2012-0287.

Packages:
- wordpress-3.3.1-1.1.mga1

x86_64

README.install.doc says..

'you need to edit your /etc/wordpress/wp-config.php file'

..which doesn't exist, there is no /etc/wordpress directory.


As far as I can tell it isn't necessary as the 'famous five minute' wordpress setup can be accessed through localhost/wordpress, although it does say there is no wp-config.php but tells you how to create it manually.

It's probably worth updating the installation instructions.


After creating the database and user and browsing to localhost/wordpress it begins the setup by asking for the database details. It says it is unable to write the config itself and gives text to paste into wp-config.php. It is able to access the database because it tells you if it can't.

When I paste the text and create wp-config.php and click to run the installer, as it says, it gives a connection reset error.

Looking in /var/log/httpd/error.log it appears to actually cause a segfault and leave a coredump in /tmp as core.<number>

I've tried with both wordpress versions and this is the same for me each time.

Is anybody able to reproduce this? Am I doing something daft?

I should say, wordpress is installed to /var/www/wordpress so wp-config.php should go there.

The install worked for me on my i586 system.

Based on http://wordpress.org/support/topic/permissions-settings-wp-configphp-possible-locations

I put wp-config.php in /var/www.

Still testing the program.

CC: (none) => davidwhodgins

Testing complete on i586.

Advisory: This security update for wordpress corrects the following CVEs.

CVE-2011-3130,wp-includes/taxonomy.php in WordPress 3.1 before 3.1.3
 and 3.2 before Beta 2 has unknown impact and attack vectors related
 to "Taxonomy query hardening," possibly involving SQL injection.

CVE-2011-3129,The file upload functionality WordPress 3.1 before
 3.1.3 and 3.2 before Beta 2, when running "on hosts with dangerous
 security settings," has unknown impact and attack vectors, possibly
 related to dangerous filenames.

CVE-2011-3128,WordPress 3.1 before 3.1.3 and 3.2 before Beta 2 treats
 unattached attachments as published, which might allow remote
 attackers to obtain sensitive data via vectors related to
 wp-includes/post.php.

CVE-2011-3127,WordPress 3.1 before 3.1.3 and 3.2 before Beta 2 does
 not prevent rendering for (1) admin or (2) login pages inside a
 frame in a third-party HTML document, which makes it easier for
 remote attackers to conduct clickjacking attacks via a crafted web
 site.

CVE-2011-3126,WordPress 3.1 before 3.1.3 and 3.2 before Beta 2 allows
 remote attackers to determine usernames of non-authors via canonical
 redirects

CVE-2011-3125,Unspecified vulnerability in WordPress 3.1 before 3.1.3
 and 3.2 before Beta 2 has unknown impact and attack vectors related
 to "Various security hardening."

CVE-2011-3122,Unspecified vulnerability in WordPress 3.1 before 3.1.3
 and 3.2 before Beta 2 has unknown impact and attack vectors related
 to "Media security."

CVE-2012-0287,Cross-site scripting (XSS) vulnerability in
 wp-comments-post.php in WordPress 3.3.x before 3.3.1, when Internet
 Explorer is used, allows remote attackers to inject arbitrary web
 script or HTML via the query string in a POST operation that is not
 properly handled by the "Duplicate comment detected" feature.

https://bugs.mageia.org/show_bug.cgi?id=4065

Tried wp-config.php in /vaw/www/ now too but no different.

Accessing localhost/wordpress or localhost/wordpress/wp-admin/install.php results in a segfault.

I can access localhost/wordpress/readme.html and other webapps without problems.


Updated php to the testing version (currently 5.3.8) but made no difference and also tried with php-eaccelerator disabled and cache cleared.

/var/log/httpd/error.log

[Mon Jan 16 10:52:33 2012] [notice] child pid 5683 exit signal Segmentation fault (11), possible coredump in /tmp

Assigning dams, please reassign when you've had a chance to take a look.
Thanks.

CC: (none) => qa-bugs
Assignee: qa-bugs => mageia

WIP, sorry for the delay...

Ping ?

Ping again.

These segfaults appear to have been caused by php-suhosin. Wordpress advises against using suhosin. Perhaps wordpress should conflict with php-suhosin?

Will the conflict be added, or since the segfaults caused by using
php-suhosin with wordpress are not a regression, should this update
be pushed as is?

Claire, am I gathering correctly based on comment 14, that it is
working on x86-64, if php-suhosin is not installed?

Yes, it installs and works fine without suhosin. IMO it should have a conflict on php-suhosin as with it installed it doesn't work.

If there are some settings which can be relaxed to allow it to function properly then that could be added maybe in a readme.urpmi but it seems easier to add the conflict to me. That's a packaging decision though :)

I created a bug with the last php update I think it was (it could have been the one before) for suhosin being overly zealous but Thomas was not keen to alter it, it is doing what it is there to do after all.

Wordpress is currently at version 3.3.2 so IMO this should be updated now before pushing.

The WordPress website still lists 3.3.2 as the latest stable version.  It's also what we have in Cauldron.

Is suhosin configurable?  If there's a way it could be configured to not interfere with wordpress, then the Conflicts isn't needed.  I don't think the Conflicts is desirable because php-cgi Requires php-suhosin, so then you wouldn't be able to have both wordpress and php-cgi installed at the same time.  Of course if such a suhosin configuration possibility exists, wordpress should probably install it.

(In reply to comment #17)
> The WordPress website still lists 3.3.2 as the latest stable version.  It's
> also what we have in Cauldron.

Oh I see, the one in updates_testing is 3.3.1.  Yes this should be updated.

Version 3.3.2 fixes CVE-2012-2399, CVE-2012-240[0-4] according to Funda Wang.

Here we are! \o/
Please test wordpress-3.3.2-1.1.mga1:
- new version 3.3.2
- update Requires to have a usable wordpress 'out of the box'
- fix README.urpmi to update path
- fix CVE-2011-3130 CVE-2011-3129 CVE-2011-3128 CVE-2011-3127 CVE-2011-3126 CVE-2011-3125 CVE-2011-3122 CVE-2012-0287 CVE-2012-2399, CVE-2012-240

Thanks!

Assignee: mageia => qa-bugs
Source RPM: wordpress-3.3.1-1.1.mga1 => wordpress-3.3.2-1.1.mga1

You shouldn't use subrel for version updates, now we have wordpress-3.3.2-1.1.mga1 > wordpress-3.3.2-1.mga2.noarch.rpm

Oops, sorry... I can submit a new package in cauldron with mkrel %2.
I can update my specfile/README.urpmi in cauldron on the same way!
My fault... I will try not to forget this next time...

Here's the Fedora update notification with some notes on CVEs fixed in 3.3.2:
http://lwn.net/Alerts/496922/

Testing x86_64

In the readme.urpmi it states..

Next, you need to edit your /var/www/wordpress/wp-config.php file to reflect the
values you've chosen.  These values will go in the appropriate places at the
beginning of that file.

There is no wp-config.php installed by the package. There is a wp-config-sample.php though.

# urpmf wordpress | grep config
wordpress:/var/www/wordpress/wp-admin/setup-config.php
wordpress:/var/www/wordpress/wp-config-sample.php
wordpress:/var/www/wordpress/wp-includes/js/tinymce/plugins/spellchecker/config.php

Either the readme.urpmi should reflect the need to rename the sample file or a wp-config.php file should be added to the package. If a wp-config.php is added then it should not automatically overwrite an existing file when it is updated and should offer rpmnew.

With the file renamed and details added, wordpress installs fine but Akismet plugin is outdated..

Akismet
You have version 2.5.3 installed. Update to 2.5.6. View version 2.5.6 details.
Compatibility with WordPress 3.3.2: 100% (according to its author)


When adding a post, uploading an image gives a permissions error..

Unable to create directory /var/www/wordpress/wp-content/uploads/2012/05. Is its parent directory writable by the server?

# ll wp-content
total 12
-rw-r--r-- 1 root root   30 May  4  2007 index.php
drwxr-xr-x 3 root root 4096 May 12 13:14 plugins/
drwxr-xr-x 4 root root 4096 May 12 13:14 themes/

(In reply to comment #24)
> Testing x86_64
> 
> In the readme.urpmi it states..
> 
> Next, you need to edit your /var/www/wordpress/wp-config.php file to reflect
> the
> values you've chosen.  These values will go in the appropriate places at the
> beginning of that file.
> 
> There is no wp-config.php installed by the package. There is a
> wp-config-sample.php though.
> 
> # urpmf wordpress | grep config
> wordpress:/var/www/wordpress/wp-admin/setup-config.php
> wordpress:/var/www/wordpress/wp-config-sample.php
> wordpress:/var/www/wordpress/wp-includes/js/tinymce/plugins/spellchecker/config.php
> 
> Either the readme.urpmi should reflect the need to rename the sample file or a
> wp-config.php file should be added to the package. If a wp-config.php is added
> then it should not automatically overwrite an existing file when it is updated
> and should offer rpmnew.

Normal behaviour. As this file is created by installer.
Once installer done, file will be renamed by installer.

> With the file renamed and details added, wordpress installs fine but Akismet
> plugin is outdated..

Normal behaviour, akismet is oudated as WP ship a "old" version.
Plugin are updated once WP is installed.

> Akismet
> You have version 2.5.3 installed. Update to 2.5.6. View version 2.5.6 details.
> Compatibility with WordPress 3.3.2: 100% (according to its author)
> 
> 
> When adding a post, uploading an image gives a permissions error..
> 
> Unable to create directory /var/www/wordpress/wp-content/uploads/2012/05. Is
> its parent directory writable by the server?
> 
> # ll wp-content
> total 12
> -rw-r--r-- 1 root root   30 May  4  2007 index.php
> drwxr-xr-x 3 root root 4096 May 12 13:14 plugins/
> drwxr-xr-x 4 root root 4096 May 12 13:14 themes/

Ok, here it's an error, will work on it.
Thanks for testing Claire!

(In reply to comment #25)
> (In reply to comment #24)
> > Testing x86_64
> > 
> > In the readme.urpmi it states..
> > 
> > Next, you need to edit your /var/www/wordpress/wp-config.php file to reflect
> > the
> > values you've chosen.  These values will go in the appropriate places at the
> > beginning of that file.
> > 
> > There is no wp-config.php installed by the package. There is a
> > wp-config-sample.php though.
> > 
> > # urpmf wordpress | grep config
> > wordpress:/var/www/wordpress/wp-admin/setup-config.php
> > wordpress:/var/www/wordpress/wp-config-sample.php
> > wordpress:/var/www/wordpress/wp-includes/js/tinymce/plugins/spellchecker/config.php
> > 
> > Either the readme.urpmi should reflect the need to rename the sample file or a
> > wp-config.php file should be added to the package. If a wp-config.php is added
> > then it should not automatically overwrite an existing file when it is updated
> > and should offer rpmnew.
> 
> Normal behaviour. As this file is created by installer.
> Once installer done, file will be renamed by installer.

Without any wp-config.php it doesn't reach the installer, it just complains that it can't connect to the database.

(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > Testing x86_64
> > > 
> > > In the readme.urpmi it states..
> > > 
> > > Next, you need to edit your /var/www/wordpress/wp-config.php file to reflect
> > > the
> > > values you've chosen.  These values will go in the appropriate places at the
> > > beginning of that file.
> > > 
> > > There is no wp-config.php installed by the package. There is a
> > > wp-config-sample.php though.
> > > 
> > > # urpmf wordpress | grep config
> > > wordpress:/var/www/wordpress/wp-admin/setup-config.php
> > > wordpress:/var/www/wordpress/wp-config-sample.php
> > > wordpress:/var/www/wordpress/wp-includes/js/tinymce/plugins/spellchecker/config.php
> > > 
> > > Either the readme.urpmi should reflect the need to rename the sample file or a
> > > wp-config.php file should be added to the package. If a wp-config.php is added
> > > then it should not automatically overwrite an existing file when it is updated
> > > and should offer rpmnew.
> > 
> > Normal behaviour. As this file is created by installer.
> > Once installer done, file will be renamed by installer.
> 
> Without any wp-config.php it doesn't reach the installer, it just complains
> that it can't connect to the database.

No. It's the normal behaviour.
Check WP website. ;-)
wp-config.php will be created BY installer.
Without this file, WP asks you to create it with a huge button.
Ok I don't have the same WP as you. :-)

# urpme wordpress
removing wordpress-3.3.2-1.1.mga1.noarch
removing package wordpress-3.3.2-1.1.mga1.noarch
Shutting down httpd: [  OK  ]
Checking configuration sanity for apache:  [  OK  ]
Starting httpd: [  OK  ]

# rm -rf /var/www/wordpress

Dropped all tables in the wordpress database.

# urpmi wordpress

    ftp://ftp.linuxcabal.org/pub/mirrors/Mageia/distrib/1/x86_64/media/core/updates_testing/wordpress-3.3.2-1.1.mga1.noarch.rpm
installing wordpress-3.3.2-1.1.mga1.noarch.rpm from /var/cache/urpmi/rpms                                                   
Preparing...                     ##########################################################################################
      1/1: wordpress             ##########################################################################################
Shutting down httpd: [  OK  ]
Checking configuration sanity for apache:  [  OK  ]
Starting httpd: [  OK  ]


From README.urpmi..

--------------
This has created an empty database called 'wordpress', created a user named
'wordpress' with a password of 'wordpress', and given the 'wordpress' user total
permission over the 'wordpress' database.  Obviously, you'll want to select a
different password, and you may want to choose different database and user
names depending on your installation.  The specific values you choose are
not constrained, they simply need to be consistent between the database and the
config file.

Next, you need to edit your /var/www/wordpress/wp-config.php file to reflect the
values you've chosen.  These values will go in the appropriate places at the
beginning of that file.

Once that's done and the database server and web server have been started,
open a web browser to http://localhost/wordpress/wp-admin/install.php and
follow the instructions given to you on the pages you see to set up the
database tables and begin publishing your blog.
---------------

# ls -l /var/www/wordpress/wp-config.php
ls: cannot access /var/www/wordpress/wp-config.php: No such file or directory

So instructions are wrong...


Browsing to http://localhost/wordpress/wp-admin/install.php
---------------

Error establishing a database connection

This either means that the username and password information in your wp-config.php file is incorrect or we can't contact the database server at localhost. This could mean your host's database server is down.

    Are you sure you have the correct username and password?
    Are you sure that you have typed the correct hostname?
    Are you sure that the database server is running?

If you're unsure what these terms mean you should probably contact your host. If you still need help you can always visit the WordPress Support Forums.
-------------------

I don't need to check WP website to see this is wrong ;-)

On WP website..

http://codex.wordpress.org/Installing_WordPress

Under the 'Famous 5-Minute Install' heading..

Step 3..

Rename the wp-config-sample.php file to wp-config.php.

http://localhost/wordpress:
There doesn't seem to be a wp-config.php file. I need this before we can get started.

Need more help? We got it.

You can create a wp-config.php file through a web interface, but this doesn't work for all server setups. The safest way is to manually create the file.

<Create a Configuration File>
>>then: http://localhost/wordpress/wp-admin/setup-config.php

NO NEED TO RENAME!! It's for manual install!
Rename will be done by installer!
I don't underdstand how you test: why didn't you follow the webGUI Claire?

Well as I've said, twice, the webGUI doesn't show!!

Following the readme.urpmi it says to browse to 

http://localhost/wordpress/wp-admin/install.php

When I do that I get the database error mentioned in comment 26 and shown in comment 28.

Shouting won't help...

Ok so it seems that when wordpress is uninstalled it leave /var/www/wp-config.php behind without renaming to rpmsave.

When wordpress is reinstalled it reads the old wp-config.php which due to new database and password  gives the database error.

The installation cannot take place because it errors without ever reacing the installer.

IMO /var/www/wp-config.php should be renamed wp-config.php.rpmsave when wordpress is uninstalled which would prevent it from trying to access old database details and causing the error.

When I manually remove this file after uninstalling and then install again it does ask to create it.

Assigning Damien again for this. Please reassign when you have had a chance to take a look.
Thanks!

Assignee: qa-bugs => mageia

More security fixes are present in the 3.4.1 release:
http://wordpress.org/news/2012/06/wordpress-3-4-1/

Ok, I rewrite the README.urpmi file and I changed rights on wordpress directory in order to enable plugins installation and configuration with Web browser.
Thanks Claire for all the remarks.
For config file, I can't do anything as it's not managed by the rpm.

Advisory:
-------------
This update of WordPress updates it to 3.4.1 not to break upgrade from Mandriva and for security fix: CVE-2011-3130, CVE-2011-3129,CVE-2011-3128, CVE-2011-3127,
CVE-2011-3126, CVE-2011-3125, CVE-2011-3122, CVE-2012-0287, CVE-2012-1835, CVE-2012-3383, CVE-2012-3384, CVE-2012-3385.
Moreover, README.urpmi is better to understand now and attributes are fix so we can now install/update plugins with Web brower or use Web GUI to install WordPress.

Packages:
-------------
wordpress-3.4.1-1.1.mga1
wordpress-3.4.1-1.1.mga2

New Suggests:
-------------
N/A

How to test:
-------------
- Install 'wordpress' from 1/2, see we can't easily configure/install it as Web GUI and README.urpmi are not working as expected.
- Install 'wordpress' from 'update_testing' and check it very easy now as rights are good for Web GUI.

Version: Cauldron => 2
Assignee: mageia => qa-bugs
Summary: missing security updates: wordpress (CVE-2011-3130 CVE-2011-3129 CVE-2011-3128 CVE-2011-3127 CVE-2011-3126 CVE-2011-3125 CVE-2011-3122 CVE-2012-0287 ) => [Update Request] - missing security updates : wordpress 3.4.1 [mga1,mga2]
Source RPM: wordpress-3.3.2-1.1.mga1 => wordpress-3.4.1-1.1.mga1

There's more specific descriptions of some of the CVEs in Comment 8 if you want to flesh out the advisory a bit.

Thanks for the work Damien.

Testing complete on Mageia 1 i586.

I'll test Mageia 2 i586 shortly.

Testing complete on Mageia 2 i586.

I did notice the README.install.urpmi is missing a semicolon on the grant.

Whiteboard: MGA2TOO, MGA1TOO => MGA2TOO, MGA1TOO MGA1-32-OK MGA2-32-OK

Testing complete mga2 x86_64

Installed release, configured, updated, installed a plugin, wrote a post and added an image.

Removed

Installed update. installed plugin, wrote a post with image.

All ok

Testing complete mga1 x86_64

Validating

Advisory and srpms for mga1 & 2 in comment 35

Could sysadmin please push from core/updates_testing to core/updates

Thanks!

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: MGA1TOO MGA1-32-OK MGA2-32-OK mga2-64-OK => MGA1TOO MGA1-32-OK MGA2-32-OK mga2-64-OK mga1-64-OK

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0168

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED