These issues were fixed in drupal 7.14 (uploaded in Cauldron by Funda Wang). It's not 100% certain, but likely that 7.0 is affected.
CC: (none) => oliver.bgr
Looks like the 7.14 wasn't really uploaded in Cauldron when I reported this. Funda has uploaded 7.14 to updates_testing for Mageia 2. Funda, can you look into this for Mageia 1 and build an update if needed?
CC: (none) => fundawang
Funda, if you find an update for Mageia 1 is needed, can you please say which CVEs are relevant? Also, Funda, do you have any references for these CVEs for the advisory? Speaking of which, uploaded so far are: drupal-7.14-1.mga2 drupal-mysql-7.14-1.mga2 drupal-postgresql-7.14-1.mga2 drupal-sqlite-7.14-1.mga2 from drupal-7.14-1.mga2.src.rpm
Funda has build an update of drupal 7.14 for Mageia 1 as well: drupal-7.14-1.mga1 drupal-mysql-7.14-1.mga1 drupal-mysqli-7.14-1.mga1 drupal-postgresql-7.14-1.mga1 drupal-sqlite-7.14-1.mga1 from drupal-7.14-1.mga1.src.rpm We can assign to QA once we have an advisory.
There is an additional vulnerability that also affects version 7.14, CVE-2012-2922, so we need another update. Fedora has issued an advisory for this on May 26: http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html
URL: (none) => http://lwn.net/Vulnerabilities/500133/Summary: drupal possible security issues CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153 => drupal possible security issues CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153, and CVE-2012-2922
Version: 1 => CauldronWhiteboard: (none) => MGA2TOO, MGA1TOO
Assignee: bugsquad => oliver.bgr
Fixed in Cauldron
(In reply to comment #5) > Fixed in Cauldron Thanks. I'll adjust the version assignments on the bug.
Version: Cauldron => 2Whiteboard: MGA2TOO, MGA1TOO => MGA1TOO
Fixed in 1 and 2: Advisory: ========= This updates fixes a vulnerability, that was reported at Fedora: http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html The request_path function in includes/bootstrap.inc in Drupal 7.14 and earlier allows remote attackers to obtain sensitive information via the q[] parameter to index.php, which reveals the installation path in an error message. See http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2922 ========= Affected packages: drupal-7.14-1.1.mga1.noarch.rpm drupal-mysql-7.14-1.1.mga1.noarch.rpm drupal-mysqli-7.14-1.1.mga1.noarch.rpm drupal-postgresql-7.14-1.1.mga1.noarch.rpm drupal-sqlite-7.14-1.1.mga1.noarch.rpm from drupal-7.14-1.1.mga1.src.rpm drupal-7.14-1.1.mga2.noarch.rpm drupal-mysql-7.14-1.1.mga2.noarch.rpm drupal-postgresql-7.14-1.1.mga2.noarch.rpm drupal-sqlite-7.14-1.1.mga2.noarch.rpm from drupal-7.14-1.1.mga2.src.rpm
Assignee: oliver.bgr => qa-bugs
Thanks Oliver. CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153 were also fixed by Drupal 5.14, so they should be included in the advisory if they apply to the version of Drupal we are replacing.
OK, I dug up the info on the other CVEs. They do all apply to Mageia 1 and 2. Advisory: ======================== Updated drupal packages fix security vulnerabilities: Drupal core's text filtering system provides several features including removing inappropriate HTML tags and automatically linking content that appears to be a link. A pattern in Drupal's text matching was found to be inefficient with certain specially crafted strings. This vulnerability is mitigated by the fact that users must have the ability to post content sent to the filter system such as a role with the "post comments" or "Forum topic: Create new content" permission (CVE-2012-1588). Drupal core's Form API allows users to set a destination, but failed to validate that the URL was internal to the site. This weakness could be abused to redirect the login to a remote site with a malicious script that harvests the login credentials and redirects to the live site. This vulnerability is mitigated only by the end user's ability to recognize a URL with malicious query parameters to avoid the social engineering required to exploit the problem (CVE-2012-1589). Drupal core's forum lists fail to check user access to nodes when displaying them in the forum overview page. If an unpublished node was the most recently updated in a forum then users who should not have access to unpublished forum posts were still be able to see meta-data about the forum post such as the post title (CVE-2012-1590). Drupal core provides the ability to have private files, including images, and Image Styles which create derivative images from an original image that may differ, for example, in size or saturation. Drupal core failed to properly terminate the page request for cached image styles allowing users to access image derivatives for images they should not be able to view. Furthermore, Drupal didn't set the right headers to prevent image styles from being cached in the browser (CVE-2012-1591). Drupal core provides the ability to list nodes on a site at admin/content. Drupal core failed to confirm a user viewing that page had access to each node in the list. This vulnerability only concerns sites running a contributed node access module and is mitigated by the fact that users must have a role with the "Access the content overview page" permission. Unpublished nodes were not displayed to users who only had the "Access the content overview page" permission (CVE-2012-2153). The request_path function in includes/bootstrap.inc in Drupal 7.14 and earlier allows remote attackers to obtain sensitive information via the q[] parameter to index.php, which reveals the installation path in an error message (CVE-2012-2922). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1588 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1589 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1590 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1591 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2153 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2922 http://drupal.org/node/1557938 http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html ======================== Updated packages in core/updates_testing: ======================== drupal-7.14-1.1.mga1 drupal-mysql-7.14-1.1.mga1 drupal-mysqli-7.14-1.1.mga1 drupal-postgresql-7.14-1.1.mga1 drupal-sqlite-7.14-1.1.mga1 drupal-7.14-1.1.mga2 drupal-mysql-7.14-1.1.mga2 drupal-postgresql-7.14-1.1.mga2 drupal-sqlite-7.14-1.1.mga2 from SRPMS: drupal-7.14-1.1.mga1.src.rpm drupal-7.14-1.1.mga2.src.rpm
Testing x86_64 Mageia 2 A few issues.. The README.urpmi gives incorrect instructions for installation. Step 1) The directory to find the INSTALL.*.txt files in in /usr/share/doc/drupal7/ where they are actually in /usr/share/doc/drupal/ Step 2) It says to copy a file from and to /etc/drupal7/sites/default/ which should be /etc/drupal/sites/default/ After completing these two steps, drupal is not accessible from anything other than localhost. It remains that way after the setup is completed. In the file /etc/httpd/conf/webapps.d/drupal.conf it is set to block the outside world but there is no mention of this. Alias /drupal /usr/share/drupal <Directory /usr/share/drupal/> Options -Indexes +FollowSymlinks +Multiviews AllowOverride None Order deny,allow Deny from all Allow from 127.0.0.1
Other than the problems in comment 10, created articles and pages and added a picture and all appears OK.
Testing Mageia 1 x86_64 There is no README.urpmi at all in mga1 # ls /usr/share/doc/drupal/ CHANGELOG.txt INSTALL.pgsql.txt LICENSE.txt robots.txt COPYRIGHT.txt INSTALL.sqlite.txt MAINTAINERS.txt UPGRADE.txt INSTALL.mysql.txt INSTALL.txt README.txt I'll install pgsql and check if the outside world exists for this one :)
Mageia 1 x86_64 has problems. Installed pgsql, there is no README.urpmi but followed INSTALL.pgsql.txt It doesn't explain that you need to su postgres before using the createuser or createdb commands. The createdb command fails without -T template0 due to the UTF8 encoding. With this completed and after renaming /var/www/drupal/sites/default/default.settings.php to settings.php, browsing either locally to localhost/drupal or remotely to host/drupal gives.. Bad Request Your browser sent a request that this server could not understand. Additionally, a 400 Bad Request error was encountered while trying to use an ErrorDocument to handle the request. This is a regression. I think these packages still need some attention so assigning back to Oliver, sorry. Please reassign QA when you've had a chance to look. Thanks.
CC: (none) => qa-bugsHardware: i586 => AllAssignee: qa-bugs => oliver.bgr
README.urpmi fixed for 2.
What's the status of this update? Is ready to handle back to QA already? latest SRPMs: drupal-7.14-1.1.mga1.src.rpm drupal-7.14-1.2.mga2.src.rpm
Whiteboard: MGA1TOO => MGA1TOO feedback
CC: (none) => oe
Funda has pushed a new build to Mageia 1 updates_testing, so it's now: drupal-7.14-1.2.mga1.src.rpm Is this ready to go?
I've updated drupal to 7.16 so that drupal SA-CORE-2012-003 is fixed. Now we have: drupal-7.16-1.mga1 drupal-7.16-1.mga2
Assigning back to QA. Upstream rates these new issues as "highly critical." The previous set of issues fixed by the 7.14 packages are rated "critical." Hopefully we can get this pushed. Advisory: ======================== Updated drupal packages fix security vulnerabilities: Drupal core's text filtering system provides several features including removing inappropriate HTML tags and automatically linking content that appears to be a link. A pattern in Drupal's text matching was found to be inefficient with certain specially crafted strings. This vulnerability is mitigated by the fact that users must have the ability to post content sent to the filter system such as a role with the "post comments" or "Forum topic: Create new content" permission (CVE-2012-1588). Drupal core's Form API allows users to set a destination, but failed to validate that the URL was internal to the site. This weakness could be abused to redirect the login to a remote site with a malicious script that harvests the login credentials and redirects to the live site. This vulnerability is mitigated only by the end user's ability to recognize a URL with malicious query parameters to avoid the social engineering required to exploit the problem (CVE-2012-1589). Drupal core's forum lists fail to check user access to nodes when displaying them in the forum overview page. If an unpublished node was the most recently updated in a forum then users who should not have access to unpublished forum posts were still be able to see meta-data about the forum post such as the post title (CVE-2012-1590). Drupal core provides the ability to have private files, including images, and Image Styles which create derivative images from an original image that may differ, for example, in size or saturation. Drupal core failed to properly terminate the page request for cached image styles allowing users to access image derivatives for images they should not be able to view. Furthermore, Drupal didn't set the right headers to prevent image styles from being cached in the browser (CVE-2012-1591). Drupal core provides the ability to list nodes on a site at admin/content. Drupal core failed to confirm a user viewing that page had access to each node in the list. This vulnerability only concerns sites running a contributed node access module and is mitigated by the fact that users must have a role with the "Access the content overview page" permission. Unpublished nodes were not displayed to users who only had the "Access the content overview page" permission (CVE-2012-2153). The request_path function in includes/bootstrap.inc in Drupal 7.14 and earlier allows remote attackers to obtain sensitive information via the q[] parameter to index.php, which reveals the installation path in an error message (CVE-2012-2922). A bug in the installer code was identified that allows an attacker to re-install Drupal using an external database server under certain transient conditions. This could allow the attacker to execute arbitrary PHP code on the original server (Drupal SA-CORE-2012-003). For sites using the core OpenID module, an information disclosure vulnerability was identified that allows an attacker to read files on the local filesystem by attempting to log in to the site using a malicious OpenID server (Drupal SA-CORE-2012-003). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1588 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1589 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1590 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1591 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2153 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2922 http://drupal.org/node/1557938 http://drupal.org/node/1815912 http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html ======================== Updated packages in core/updates_testing: ======================== drupal-7.16-1.mga1 drupal-mysql-7.16-1.mga1 drupal-mysqli-7.16-1.mga1 drupal-postgresql-7.16-1.mga1 drupal-sqlite-7.16-1.mga1 drupal-7.16-1.mga2 drupal-mysql-7.16-1.mga2 drupal-postgresql-7.16-1.mga2 drupal-sqlite-7.16-1.mga2 from SRPMS: drupal-7.16-1.mga1.src.rpm drupal-7.16-1.mga2.src.rpm
Assignee: oliver.bgr => qa-bugsWhiteboard: MGA1TOO feedback => MGA1TOOSeverity: normal => critical
tested for mga2 (x86_64) for mysql, sqlite and postgresql database. Everything seems to works fine after update. Only INSTALL.pgsql.txt has the same issues than explained by Claire in Comment 13: It doesn't explain that you need to su postgres before using the createuser or createdb commands. The createdb command fails without -T template0 due to the UTF8 encoding. Also it is not accessible from outside of localhost as stated in comment 10. Does this needs to be changed, or is it OK? (all other mentioned issues from these comments seem to be fixed).
CC: (none) => marc.lattemann
Has the drupal-mysqli package intentionally been dropped, or is there a build or mirror problem? It isn't in ftp://mageia.webconquest.com/distrib/1/i586/media/core/updates_testing/ although the other drupal packages are there.
CC: (none) => davidwhodgins
(In reply to comment #20) > Has the drupal-mysqli package intentionally been dropped, or is there a build > or mirror problem? No, it is wanted. There is another packaging bug in drupal for mga1. Since 7.0, drupal started to use php-pdo as its database abstraction layer. That means, drupal no long accesses the database server via php-mysql nor php-mysqli, it needs php-pdo_mysql. So the package in drupal for mga1 is wrongly packaged in the past.
Testing complete on Mageia 2 i586 and x86-64. Used mysql on one, postgresql on the other. For Mageia 1, right now, installing drupal using the defaults fails, as it is defaulting to the older mysqli package, which can't be installed with the newer drupal. I think the update needs to obsolete the older packages so that it will install cleanly.
Whiteboard: MGA1TOO => MGA1TOO MGA2-32-OK MGA2-64-OK
Funda, could you look into this please. (comment 22) We can't push mga2 separately as a new mga1 version would have a higher version than the current mga2.
Whiteboard: MGA1TOO MGA2-32-OK MGA2-64-OK => MGA1TOO MGA2-32-OK MGA2-64-OK feedback
Could somebody remove drupal-7.16-1.mga1 from core/updates_testing? So that updated packages could be pushed. Thanks.
It can only be removed by the sysadmins. I just asked on IRC.
CC: (none) => sysadmin-bugs
Funda, Thomas Backlund tells me has just deleted drupal in Mageia 1 updates_testing, so it's free to fix and resubmit now.
drupal-7.16-1.mga1 has been fixed and reuploaded by Funda. Thanks Funda.
Whiteboard: MGA1TOO MGA2-32-OK MGA2-64-OK feedback => MGA1TOO MGA2-32-OK MGA2-64-OK
Installing the update for drupal stops php applications such as phpmyadmin from working. They return a 400 http status code to the web browser. Keeping the /etc/httpd/conf/webapps.d/drupal.conf file from the release version of drupal, allows phpmyadmin to work again. This is on a Mageia 1 i586 installation.
According to comment#28, I'm backporting the drupal package from mga2 to mga1. So, please kill again drupal in core/updates_testing for mga1. So that updated package could be uploaded.
drupal in mga1 core/updates_testing dropped
CC: (none) => tmb
drupal-7.16-0.1.mga1 submitted by Funda. Updating the advisory for the changed release tag. Advisory: ======================== Updated drupal packages fix security vulnerabilities: Drupal core's text filtering system provides several features including removing inappropriate HTML tags and automatically linking content that appears to be a link. A pattern in Drupal's text matching was found to be inefficient with certain specially crafted strings. This vulnerability is mitigated by the fact that users must have the ability to post content sent to the filter system such as a role with the "post comments" or "Forum topic: Create new content" permission (CVE-2012-1588). Drupal core's Form API allows users to set a destination, but failed to validate that the URL was internal to the site. This weakness could be abused to redirect the login to a remote site with a malicious script that harvests the login credentials and redirects to the live site. This vulnerability is mitigated only by the end user's ability to recognize a URL with malicious query parameters to avoid the social engineering required to exploit the problem (CVE-2012-1589). Drupal core's forum lists fail to check user access to nodes when displaying them in the forum overview page. If an unpublished node was the most recently updated in a forum then users who should not have access to unpublished forum posts were still be able to see meta-data about the forum post such as the post title (CVE-2012-1590). Drupal core provides the ability to have private files, including images, and Image Styles which create derivative images from an original image that may differ, for example, in size or saturation. Drupal core failed to properly terminate the page request for cached image styles allowing users to access image derivatives for images they should not be able to view. Furthermore, Drupal didn't set the right headers to prevent image styles from being cached in the browser (CVE-2012-1591). Drupal core provides the ability to list nodes on a site at admin/content. Drupal core failed to confirm a user viewing that page had access to each node in the list. This vulnerability only concerns sites running a contributed node access module and is mitigated by the fact that users must have a role with the "Access the content overview page" permission. Unpublished nodes were not displayed to users who only had the "Access the content overview page" permission (CVE-2012-2153). The request_path function in includes/bootstrap.inc in Drupal 7.14 and earlier allows remote attackers to obtain sensitive information via the q[] parameter to index.php, which reveals the installation path in an error message (CVE-2012-2922). A bug in the installer code was identified that allows an attacker to re-install Drupal using an external database server under certain transient conditions. This could allow the attacker to execute arbitrary PHP code on the original server (Drupal SA-CORE-2012-003). For sites using the core OpenID module, an information disclosure vulnerability was identified that allows an attacker to read files on the local filesystem by attempting to log in to the site using a malicious OpenID server (Drupal SA-CORE-2012-003). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1588 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1589 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1590 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1591 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2153 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2922 http://drupal.org/node/1557938 http://drupal.org/node/1815912 http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html ======================== Updated packages in core/updates_testing: ======================== drupal-7.16-0.1.mga1 drupal-mysql-7.16-0.1.mga1 drupal-postgresql-7.16-0.1.mga1 drupal-sqlite-7.16-0.1.mga1 drupal-7.16-1.mga2 drupal-mysql-7.16-1.mga2 drupal-postgresql-7.16-1.mga2 drupal-sqlite-7.16-1.mga2 from SRPMS: drupal-7.16-1.mga1.src.rpm drupal-7.16-1.mga2.src.rpm
Oops, missed the SRPM. Advisory: ======================== Updated drupal packages fix security vulnerabilities: Drupal core's text filtering system provides several features including removing inappropriate HTML tags and automatically linking content that appears to be a link. A pattern in Drupal's text matching was found to be inefficient with certain specially crafted strings. This vulnerability is mitigated by the fact that users must have the ability to post content sent to the filter system such as a role with the "post comments" or "Forum topic: Create new content" permission (CVE-2012-1588). Drupal core's Form API allows users to set a destination, but failed to validate that the URL was internal to the site. This weakness could be abused to redirect the login to a remote site with a malicious script that harvests the login credentials and redirects to the live site. This vulnerability is mitigated only by the end user's ability to recognize a URL with malicious query parameters to avoid the social engineering required to exploit the problem (CVE-2012-1589). Drupal core's forum lists fail to check user access to nodes when displaying them in the forum overview page. If an unpublished node was the most recently updated in a forum then users who should not have access to unpublished forum posts were still be able to see meta-data about the forum post such as the post title (CVE-2012-1590). Drupal core provides the ability to have private files, including images, and Image Styles which create derivative images from an original image that may differ, for example, in size or saturation. Drupal core failed to properly terminate the page request for cached image styles allowing users to access image derivatives for images they should not be able to view. Furthermore, Drupal didn't set the right headers to prevent image styles from being cached in the browser (CVE-2012-1591). Drupal core provides the ability to list nodes on a site at admin/content. Drupal core failed to confirm a user viewing that page had access to each node in the list. This vulnerability only concerns sites running a contributed node access module and is mitigated by the fact that users must have a role with the "Access the content overview page" permission. Unpublished nodes were not displayed to users who only had the "Access the content overview page" permission (CVE-2012-2153). The request_path function in includes/bootstrap.inc in Drupal 7.14 and earlier allows remote attackers to obtain sensitive information via the q[] parameter to index.php, which reveals the installation path in an error message (CVE-2012-2922). A bug in the installer code was identified that allows an attacker to re-install Drupal using an external database server under certain transient conditions. This could allow the attacker to execute arbitrary PHP code on the original server (Drupal SA-CORE-2012-003). For sites using the core OpenID module, an information disclosure vulnerability was identified that allows an attacker to read files on the local filesystem by attempting to log in to the site using a malicious OpenID server (Drupal SA-CORE-2012-003). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1588 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1589 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1590 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1591 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2153 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2922 http://drupal.org/node/1557938 http://drupal.org/node/1815912 http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html ======================== Updated packages in core/updates_testing: ======================== drupal-7.16-0.1.mga1 drupal-mysql-7.16-0.1.mga1 drupal-postgresql-7.16-0.1.mga1 drupal-sqlite-7.16-0.1.mga1 drupal-7.16-1.mga2 drupal-mysql-7.16-1.mga2 drupal-postgresql-7.16-1.mga2 drupal-sqlite-7.16-1.mga2 from SRPMS: drupal-7.16-0.1.mga1.src.rpm drupal-7.16-1.mga2.src.rpm
Testing mga1 32
Installed release version with drupal-mysqli. Manually installed php-pdo_mysql then created a db and performed the web based installation. Added an article with an image uploaded. The update installed drupal and drupal-mysql. Doing so restricted http://host/drupal to only being accessible from localhost and also clobbered the existing installation, returning to the start of the initial web based setup. The database is still there though. I'll install with drupal-mysql instead and see if the 'i' makes a difference.
Further testing shows that if the web based installation is followed using the same database details it completes and enables you to view the site. I notice in the readme.urpmi it does mention restricting access to localhost. There are problems though. The article I previously created, with an image, shows some errors and the image is now missing.. Notice: Undefined index: width in theme_image_style() (line 1256 of /usr/share/drupal/modules/image/image.module). Notice: Undefined index: height in theme_image_style() (line 1257 of /usr/share/drupal/modules/image/image.module). Logging in and editing the article shows it still has a link to the image and a size in kb but when clicking on the link a small window opens at http://localhost/drupal/sites/default/files/field/image/120thCenturyFox.jpg saying that it can't now be found.. 'The requested URL "/drupal/sites/default/files/field/image/120thCenturyFox.jpg" was not found on this server.' # ll /var/www/drupal/sites/default/files/field/image/120thCenturyFox.jpg -rw-rw-r-- 1 apache apache 25148 Oct 29 13:16 /var/www/drupal/sites/default/files/field/image/120thCenturyFox.jpg I guess this is due to .. Alias /drupal /usr/share/drupal in /etc/httpd/conf/webapps.d/drupal.conf
If the application code is going to be stored under /usr/share, that's one thing (although I don't really understand why we're starting to move a bunch of webapps there in Cauldron), but if it is going to save uploaded content and additional variable data, that needs to be under /var somewhere still and not in /usr. We need to be careful of this with web packages in general.
CC: (none) => guillomovitch
mga2 is not affected by this so could now be pushed separately if you need more time to look into this.
Fedora has issued an advisory for the newer issue on October 18: http://lists.fedoraproject.org/pipermail/package-announce/2012-October/090861.html from http://lwn.net/Vulnerabilities/521931/
Bug 7944 created for mga2 update which is waiting to be pushed. Please use this bug now for Mga1 only.
Version: 2 => 1Summary: drupal possible security issues CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153, and CVE-2012-2922 => drupal possible security issues CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153, and CVE-2012-2922 [mga1]Whiteboard: MGA1TOO MGA2-32-OK MGA2-64-OK feedback => feedback
Assigning Fundu. Please eassign to QA when you've had a chance to look at this. Thanks!
Assignee: qa-bugs => fundawangWhiteboard: feedback => (none)
Does fresh install work without problems? If yes, then there are some problems during package updating.
Ping. What's the status of this? We're running out of time to fix things for Mageia 1.
CC: guillomovitch => (none)
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => WONTFIX