A few tomcat5 vulnerabilities are listed on this page, with links with patches : http://tomcat.apache.org/security-5.html
As no maintainer I add the most commiter of this package.
CC: (none) => dmorganec
Assignee: bugsquad => dmorganec
Ping ?
i am on it now
available on testing
Assignee: dmorganec => qa-bugs
No poc, so just testing that it works. I installed tomcat5-admin-webapps, edited /etc/tomcat5/tomcat-users.xml to set up a user with the role of manager. Started the tomcat5 server. Loaded http://127.0.0.1:8080, selected the Tomcat Manager (logged in), Selected various applications by path, to confirm they are working. Testing complete on i586 for the srpm tomcat5-5.5.31-3.1.mga1.src.rpm
CC: (none) => davidwhodgins
We still need x86-64 testing for tomcat5. See comment 7 for details.
Testing x86_64 http://localhost:8080 just displays a blank page.
http://localhost:8080/admin shows the server administration login screen. Entered the user and password I'd set up and it denied access and appears now to have blocked me from accessing the login screen.
Whichever user I attempt to log in with it gives HTTP Status 403 - Access to the requested resource has been denied Then it won't allow access to the admin/login screen again until the service is restarted.
Downloaded the sample hello world webapp from http://tomcat.apache.org/tomcat-5.5-doc/appdev/sample/ into /usr/share/tomcat5/webapps/ accessed http://loclahost:8080/sample Results ------- Sample "Hello, World" Application This is the home page for a sample application used to illustrate the source directory organization of a web application utilizing the principles outlined in the Application Developer's Guide. To prove that they work, you can execute either of the following links: To a JSP page. To a servlet. ---------- Clicking on the JSP page gave another error -------- HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Unable to compile class for JSP org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:573) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:308) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) root cause java.io.FileNotFoundException: /usr/share/tomcat5/work/Catalina/localhost/sample/org/apache/jsp/hello_jsp.java (No such file or directory) java.io.FileOutputStream.open(Native Method) java.io.FileOutputStream.<init>(FileOutputStream.java:209) java.io.FileOutputStream.<init>(FileOutputStream.java:99) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:141) org.apache.jasper.compiler.Compiler.compile(Compiler.java:317) org.apache.jasper.compiler.Compiler.compile(Compiler.java:298) org.apache.jasper.compiler.Compiler.compile(Compiler.java:286) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:565) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:308) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.31 logs. --------------- Appears to be a file not found but it could be a result of using the downloaded example and not one of our packaged ones which I don't know how to access. Clicking on servlet link gives better results.. -------------- Sample Application Servlet This is the output of a servlet that is part of the Hello, World application. --------------- Can anybody say if this appears to be normal behaviour??
Good catch Claire. /var/cache/tomcat5/work has to be group writable, but isn't. I changed it on my system, and the jsp page now works. Should the /var/cache/tomcat5/temp be group writable as well?
Re-assigning back to the developer for the permissions problem in /var/cache/tomcat5/
CC: (none) => qa-bugsAssignee: qa-bugs => dmorganec
please test again now
Testing complete on i586 for the srpm tomcat5-5.5.31-4.1.mga1.src.rpm Testing method same as comment 12.
14/14: tomcat5 ############################################# /usr/bin/build-jar-repository: error: Could not find javamail/mail Java extension for this JVM /usr/bin/build-jar-repository: error: Some specified jars were not found for this jvm strange because jpackage-utils is installed, but not a blocker I guess ? (an I a found a bug, if apache is in the skip.list it does'nt work, conflict with jakarta, but that's not the subject :) ) For the rest it's ok for me too (x86_64)
This may still be missing an update for CVE-2010-3718. Here's the advisory from Mandriva on February 18: http://lists.mandriva.com/security-announce/2011-02/msg00012.php
CC: (none) => luigiwalser
CVE-2010-3718 is fixed in tomcat 5.5.30 and in mga1 we have tomcat 5.5.31 so this is not needed see : http://tomcat.apache.org/security-5.html#Fixed_in_Apache_Tomcat_5.5.30
(In reply to comment #17) > 14/14: tomcat5 ############################################# > /usr/bin/build-jar-repository: error: Could not find javamail/mail Java > extension for this JVM > /usr/bin/build-jar-repository: error: Some specified jars were not found for > this jvm > > strange because jpackage-utils is installed, but not a blocker I guess ? > > (an I a found a bug, if apache is in the skip.list it does'nt work, conflict > with jakarta, but that's not the subject :) ) > > For the rest it's ok for me too (x86_64) i would like to see this fixed, this is a missing requires i look at it now
Please test next tomcat5 rpm
I still get the same error, but can somebody reproduce from the QA ?
With tomcat5-5.5.31-4.2.mga1.src.rpm ll /var/cache/tomcat5/ total 8 drwxr-xr-x 2 root tomcat 4096 Jan 1 15:39 temp/ drwxr-xr-x 2 root tomcat 4096 Jan 1 15:39 work/ The directories are not group writable.
i think this is because of your previous install. can you remove tomcat5, make sure /var/cache/tomcat5/ doesn't exist anymore and reinstall.
I did that before reporting comment 23.
can you : 1- remove tomcat5 2- install javamail 3- install tomcat5
There is a minor problem with the init script for tomcat5 also. It seems to overwrite its own output and then ends on the same line too. The strange result is shown below. # service tomcat5 restart # 5: [ OK ] Also whilst already started.. # service tomcat5 start Starting tomcat5: tomcat5 process already running /etc/init.d/tomcat5: line 168: return: -1: invalid option return: usage: return [n] # [ OK ] # service tomcat5 stop # 5: [ OK ] Once stopped.. # service tomcat5 stop # 5: [FAILED] It doesn't seem to affect the operation but should probably be checked. I can confirm that with the update the permissions problem is not fixed. I will remove and install javamail first as you suggest but if successful we should provide the fix in the update without requiring such user action.
x86_64 # urpme -a tomcat5 removing package tomcat5-common-lib-0:5.5.31-4.2.mga1.noarch removing package struts-0:1.2.9-10.mga1.noarch removing package eclipse-cdt-1:7.0.1-2.mga1.x86_64 removing package eclipse-rse-3.2-1.mga1.noarch removing package eclipse-emf-2.6.0-3.mga1.noarch removing package eclipse-platform-1:3.6.2-12.mga1.x86_64 removing package ant-apache-bsf-0:1.8.2-4.mga1.noarch removing package bsf-0:2.4.0-1.8.mga1.noarch removing package jakarta-commons-fileupload-1:1.2.1-2.0.6.mga1.noarch removing package tomcat5-jsp-2.0-api-0:5.5.31-4.2.mga1.noarch removing package tomcat5-server-lib-0:5.5.31-4.2.mga1.noarch removing package tomcat5-jasper-0:5.5.31-4.2.mga1.noarch removing package tomcat5-servlet-2.4-api-0:5.5.31-4.2.mga1.noarch removing package tomcat5-jasper-eclipse-0:5.5.31-4.2.mga1.noarch # ls /var/cache cups/ gdm/ httpd/ ldconfig/ mindi/ samba/ dirmngr/ gstreamer-0.10/ jetty/ libvirt/ mondo/ urpmi/ fontconfig/ hald/ jetty5/ man/ php-pear/ # ls /usr/share/tomcat5/ bin/ # ls /usr/share/tomcat5/bin commons-daemon.jar@ commons-logging-api.jar@ tomcat-juli.jar@ # rm -rf /usr/share/tomcat5 # urpmi javamail ftp://ftp.linuxcabal.org/pub/mirrors/Mageia/distrib/1/x86_64/media/core/release/javamail-1.4.3-7.mga1.noarch.rpm installing javamail-1.4.3-7.mga1.noarch.rpm from /var/cache/urpmi/rpms Preparing... ############################################# 1/1: javamail ############################################# Seems javamail wasn't installed originally. # urpmi tomcat5 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Updates Testing") tomcat5 5.5.31 4.2.mga1 noarch tomcat5-common-lib 5.5.31 4.2.mga1 noarch tomcat5-jasper 5.5.31 4.2.mga1 noarch tomcat5-jsp-2.0-api 5.5.31 4.2.mga1 noarch tomcat5-server-lib 5.5.31 4.2.mga1 noarch tomcat5-servlet-2.4-api 5.5.31 4.2.mga1 noarch 3MB of additional disk space will be used. 2.6MB of packages will be retrieved. Proceed with the installation of the 6 packages? (Y/n) y # service tomcat5 start # 5: [ OK ] # urpmi tomcat5-admin-webapps In order to satisfy the 'jakarta-commons-fileupload' dependency, one of the following packages is needed: 1- apache-commons-fileupload-1.2.2-3.mga1.noarch: This package provides an api to work with html file upload (to install) 2- jakarta-commons-fileupload-1.2.1-2.0.6.mga1.noarch: Jakarta Commons Fileupload Package (to install) What is your choice? (1-2) 1 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") apache-commons-fileupload 1.2.2 3.mga1 noarch struts 1.2.9 10.mga1 noarch (medium "Core Updates Testing") tomcat5-admin-webapps 5.5.31 4.2.mga1 noarch Added manager user in /etc/tomcat5/tomcat-users.xml <user name="tomtest" password="tomtest" roles="manager" /> # service tomcat5 restart # 5: [ OK ] # ll /var/cache/tomcat5 total 8 drwxr-xr-x 2 root tomcat 4096 Jan 1 20:39 temp/ drwxr-xr-x 2 root tomcat 4096 Jan 1 20:39 work/ # ll /var/cache/tomcat5/temp total 0 # ll /var/cache/tomcat5/work total 0 Browsing to http://loclahost:8080/admin takes me to the login page but as before unable to log in.. HTTP Status 403 - Access to the requested resource has been denied type Status report message Access to the requested resource has been denied description Access to the specified resource (Access to the requested resource has been denied) has been forbidden.
i told to remove /var/cache/tomcat5 no /usr/share/tomcat5 ( to verify the new rights ) ;)
Well with a clean tomcat5 install it still exists. 'SEVERE' Problems in the logs all point to not being able to access the /var/cache/tomcat5/work directory.
is /var/cache/tomcat5/work 770 ?
can you attach your logs please ?
(In reply to comment #31) > is /var/cache/tomcat5/work 770 ? No. After uninstalling tomcat5, ensuring /var/cache/tomcat5 does not exist, then installing tomcat5 tomcat5-admin-webapps tomcat5-webapps the work directory is 755.
dmorgan do you still need logs for this? If so I will reinstall and test again.
yes please i still need ( to understand what is wrong )
After removing tomcat5 and tomcat5-admin-webapps and removing /var/cache/tomcat5 manually. Installed release version tomcat5 & tomcat5-admin-webapps. # ll /var/cache/tomcat5/ total 8 drwxrwx--- 2 root tomcat 4096 Feb 11 2011 temp/ drwxrwx--- 2 root tomcat 4096 Feb 11 2011 work/ Updated to Testing version # ll /var/cache/tomcat5/ total 8 drwxr-xr-x 2 root tomcat 4096 Jan 1 20:39 temp/ drwxr-xr-x 2 root tomcat 4096 Jan 1 20:39 work/ Added to /etc/tomcat5/tomcat-users.xml <user name="manager" password="manager" roles="manager" /> # service tomcat5 start # [ OK ] init script is still a bit messed up, it overwrites the same line rather than using new lines. Browsing to localhost:8080/admin takes me to a login screen. Entered manager/manager but I'm unable to log in whichever username I try. From /var/log/tomcat5/catalina.2012-01-19.log SEVERE: The scratchDir you specified: /usr/share/tomcat5/work/Catalina/localhost/host-manager is unusable. 19-Jan-2012 10:12:16 org.apache.catalina.startup.TldConfig execute WARNING: Error trying to write a TLD cache file for context path [/balancer] java.io.FileNotFoundException: /usr/share/tomcat5/work/Catalina/localhost/balancer /tldCache.ser (No such file or directory) # ll /usr/share/tomcat5/ total 4 drwxr-xr-x 2 root root 4096 Jan 19 09:59 bin/ lrwxrwxrwx 1 root root 31 Jan 19 09:59 common -> ../../../var/lib/tomcat5/common/ lrwxrwxrwx 1 root root 20 Jan 19 09:59 conf -> ../../../etc/tomcat5/ lrwxrwxrwx 1 root root 24 Jan 19 09:59 logs -> ../../../var/log/tomcat5/ lrwxrwxrwx 1 root root 31 Jan 19 09:59 server -> ../../../var/lib/tomcat5/server/ lrwxrwxrwx 1 root root 31 Jan 19 09:59 shared -> ../../../var/lib/tomcat5/shared/ lrwxrwxrwx 1 root root 31 Jan 19 09:59 temp -> ../../../var/cache/tomcat5/temp/ lrwxrwxrwx 1 root root 32 Jan 19 09:59 webapps -> ../../../var/lib/tomcat5/webapps/ lrwxrwxrwx 1 root root 31 Jan 19 09:59 work -> ../../../var/cache/tomcat5/work/ Should the links be root:tomcat? I'll attach the relevant log files.
Created attachment 1390 [details] /var/log/tomcat5/catalina.2012-01-19.log
Created attachment 1391 [details] /var/log/tomcat5/catalina.out
Looking at the tomcat5.spec file (I know very little about spec files), I notice the line %attr(0660,root,tomcat) %config(noreplace) %{confdir}/logging.properties does result in /etc/tomcat5/logging.properties having Access: (0660/-rw-rw----), with no other references to logging.properties in the spec file. For /var/cache/tomcat5/work, the spec lines ... %define workdir %{_var}/cache/%{name}/work %{__install} -d -m 755 ${RPM_BUILD_ROOT}{%{serverdir},%{tempdir},%{workdir}} [ -d work ] || %{__ln_s} -f %{workdir} work # Always clean up workdir and tempdir on upgrade/removal %{__rm} -fr %{workdir}/* %{tempdir}/* %{_datadir}/%{name}/work %attr(0770,root,tomcat) %dir %{workdir} result in /var/cache/tomcat5/work having Access: (0755/drwxr-xr-x) For /var/cache/tomcat5/temp, the spec lines ... %define tempdir %{_var}/cache/%{name}/temp %{__install} -d -m 755 ${RPM_BUILD_ROOT}{%{serverdir},%{tempdir},%{workdir}} [ -d temp ] || %{__ln_s} -f %{tempdir} temp # Always clean up workdir and tempdir on upgrade/removal %{__rm} -fr %{workdir}/* %{tempdir}/* %{_datadir}/%{name}/temp %attr(0770,root,tomcat) %dir %{tempdir} %attr(0775,root,tomcat) %dir %{_var}/cache/%name/temp result in /var/cache/tomcat5/temp having Access: (0755/drwxr-xr-x) My guess, is that since the directories are created by the the install with 0755, the later attr spec lines are ignored.
Assignee: qa-bugs => dmorganec
Ping. The permissions for the directories in /var/cache/tomcat5/ still need to be corrected.
i will look
Any news ?
I believe these vulnerabilities are also relevant in Cauldron.
Blocks: (none) => 5046
Ping. This is a security update. Please take a look at comment 39.
I found two more CVEs affecting this package: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4858 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0022
(In reply to comment #45) > I found two more CVEs affecting this package: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4858 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0022 Here is a reference to where these were fixed in tomcat6 in Ubuntu: http://www.ubuntu.com/usn/usn-1359-1/ See also Bug 5261
(In reply to comment #46) > (In reply to comment #45) > > I found two more CVEs affecting this package: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4858 > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0022 > > Here is a reference to where these were fixed in tomcat6 in Ubuntu: > http://www.ubuntu.com/usn/usn-1359-1/ > > See also Bug 5261 We are indeed missing patches for these vulnerabilities in Mageia 1 updates_testing and Cauldron. These were fixed (noted that their fixes overlap) in 5.5.35. The ones we already have patches for were fixed in 5.5.34. Here's another reference: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4858
i fixed all CVE from http://tomcat.apache.org/security-5.html i will backport on mageia 1 now
dmorgan: did you correct the permissions problem also? See comment 36 - Dave found a possible issue in the spec in comment 39
Blocks: 5046 => (none)
The permissions for the directories in /var/cache/tomcat5/ still need to be corrected. Either they need to be made group writable, or changed to be owned by tomcat.
pi,,g ?
Just an FYI that Mandriva has issued an advisory for the last two CVEs that were fixed here: http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:085
we will do like in F15/16 and only package the APIs
There is no test to do as there is no webapps anymore. we just need to validate this.
What of people who already have the webapps package installed?
It never worked and as we still provide this apps we can't add an obsolete in tomcat6 package. if you have an idea i am all ears
Nope. How do you suggest testing without the webapps package?
there is no test to do. just check that it installs OK.
Testing mga1 x86_64 Installed tomcat5 and tomcat5-webapps When updating.. The following packages have to be removed for others to be upgraded: tomcat5-5.5.31-3.mga1.noarch (due to unsatisfied tomcat5-server-lib == 0:5.5.31-3.mga1, due to unsatisfied tomcat5-server-lib == 0:5.5.31-3.mga1) tomcat5-server-lib-5.5.31-3.mga1.noarch (due to unsatisfied tomcat5-jasper == 0:5.5.31-3.mga1, due to unsatisfied tomcat5-jasper == 0:5.5.31-3.mga1) tomcat5-webapps-5.5.31-3.mga1.noarch (due to unsatisfied tomcat5 == 0:5.5.31-3.mga1) This appears to be affected by bug 2317 so setting a depends. Working around that by setting Release as updates. # ./depcheck tomcat5 "Core Release" "Core Updates Testing" ---------------------------------------- Running checks for "tomcat5" using media "Core Release" and "Core Updates Testing". ---------------------------------------- Mageia release 1 (Official) for x86_64 Latest version found in "Core Release" is tomcat5-5.5.31-3.mga1 Latest version found in "Core Updates Testing" is tomcat5-5.5.31-4.4.mga1 ---------------------------------------- The following packages will require linking: apache-commons-launcher-1.1-7.20100521svn936225.2.mga1 (Core 32bit Release) apache-commons-launcher-1.1-7.20100521svn936225.2.mga1 (Core Release) apache-commons-modeler-2.0.1-8.mga1 (Core 32bit Release) apache-commons-modeler-2.0.1-8.mga1 (Core Release) java-1.5.0-gcj-devel-1.5.0.0-17.1.22.mga1 (Core 32bit Release) java-1.5.0-gcj-devel-1.5.0.0-17.1.22.mga1 (Core Release) java-1.6.0-openjdk-devel-1.6.0.0-14.b22.5.mga1 (Core 32bit Release) java-1.6.0-openjdk-devel-1.6.0.0-14.b22.5.1.mga1 java-1.6.0-openjdk-devel-1.6.0.0-24.b22.6.1.mga1 java-1.6.0-openjdk-devel-1.6.0.0-26.b22.1.mga1 (Core 32bit Updates) java-1.6.0-openjdk-devel-1.6.0.0-14.b22.5.mga1 (Core Release) java-1.6.0-openjdk-devel-1.6.0.0-14.b22.5.1.mga1 java-1.6.0-openjdk-devel-1.6.0.0-24.b22.6.1.mga1 java-1.6.0-openjdk-devel-1.6.0.0-26.b22.1.mga1 (Core Updates) java-1.6.0-openjdk-devel-1.6.0.0-28.b22.1.mga1 (Core Updates Testing) java-1.6.0-sun-devel-1.6.0.25-1.mga1 (Nonfree Release) java-1.6.0-sun-devel-1.6.0.26-0.2.mga1.nonfree (Nonfree Updates) ---------------------------------------- Done.
Depends on: (none) => 2317
After the update restarted the service and browsed to localhost:8080 Couldn't get any further due to the permissions problem but the update went OK, if that is sufficient testing. Testing complete x86_64 Mageia 1
Could you provide an advisory please dmorgan. Thanks.
Advisory: A vulnerability has been discovered and corrected in tomcat5: Apache Tomcat 5.5.x before 5.5.35, 6.x before 6.0.34, and 7.x before 7.0.23 uses an inefficient approach for handling parameters, which allows remote attackers to cause a denial of service (CPU consumption) via a request that contains many parameters and parameter values, a different vulnerability than CVE-2011-4858 (CVE-2012-0022). The updated packages have been patched to correct this issue.
Whiteboard: (none) => mga1-64-OK
The advisory will need to explain the recent changes made to the package. As far as CVEs, these are the ones fixed: - CVE-2011-0013 - CVE-2011-1184 - CVE-2011-2204 - CVE-2011-2526 - CVE-2011-2729 - CVE-2011-3190 - CVE-2011-4858 - CVE-2012-0022 We have descriptions for all of these CVEs on Bug 5261 except for two: Multiple cross-site scripting (XSS) vulnerabilities in the HTML Manager Interface in Apache Tomcat 5.5 before 5.5.32, 6.0 before 6.0.30, and 7.0 before 7.0.6 allow remote attackers to inject arbitrary web script or HTML, as demonstrated via the display-name tag (CVE-2011-0013). native/unix/native/jsvc-unix.c in jsvc in the Daemon component 1.0.3 through 1.0.6 in Apache Commons, as used in Apache Tomcat 5.5.32 through 5.5.33, 6.0.30 through 6.0.32, and 7.0.x before 7.0.20 on Linux, does not drop capabilities, which allows remote attackers to bypass read permissions for files via a request to an application (CVE-2011-2729). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0013 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2729 http://tomcat.apache.org/security-5.html Packages built for this update by D Morgan: tomcat5-5.5.31-4.4.mga1.noarch.rpm tomcat5-webapps-5.5.31-4.4.mga1.noarch.rpm tomcat5-admin-webapps-5.5.31-4.4.mga1.noarch.rpm tomcat5-servlet-2.4-api-5.5.31-4.4.mga1.noarch.rpm tomcat5-servlet-2.4-api-javadoc-5.5.31-4.4.mga1.noarch.rpm tomcat5-jsp-2.0-api-5.5.31-4.4.mga1.noarch.rpm tomcat5-jsp-2.0-api-javadoc-5.5.31-4.4.mga1.noarch.rpm tomcat5-common-lib-5.5.31-4.4.mga1.noarch.rpm tomcat5-server-lib-5.5.31-4.4.mga1.noarch.rpm tomcat5-jasper-5.5.31-4.4.mga1.noarch.rpm tomcat5-jasper-javadoc-5.5.31-4.4.mga1.noarch.rpm tomcat5-jasper-eclipse-5.5.31-4.4.mga1.noarch.rpm from tomcat5-5.5.31-4.4.mga1.src.rpm
Testing complete i586 Mageia 1 Same way, same thing. It seems depcheck has become bruised and battered over the months of use and tinkering. When printing the results, with the media they were in, it wasn't excluding Updates medias when doing urpmf -m so added --excludemedia Updates on line 139 to rectify it. ./depcheck tomcat5 "Core Release" "Core Updates Testing" ---------------------------------------- Running checks for "tomcat5" using media "Core Release" and "Core Updates Testing". ---------------------------------------- Mageia release 1 (Official) for x86_64 Latest version found in "Core Release" is tomcat5-5.5.31-3.mga1 Latest version found in "Core Updates Testing" is tomcat5-5.5.31-4.4.mga1 ---------------------------------------- The following packages will require linking: apache-commons-launcher-1.1-7.20100521svn936225.2.mga1 (Core 32bit Release) apache-commons-launcher-1.1-7.20100521svn936225.2.mga1 (Core Release) apache-commons-modeler-2.0.1-8.mga1 (Core 32bit Release) apache-commons-modeler-2.0.1-8.mga1 (Core Release) java-1.5.0-gcj-devel-1.5.0.0-17.1.22.mga1 (Core 32bit Release) java-1.5.0-gcj-devel-1.5.0.0-17.1.22.mga1 (Core Release) java-1.6.0-openjdk-devel-1.6.0.0-14.b22.5.mga1 (Core 32bit Release) java-1.6.0-openjdk-devel-1.6.0.0-14.b22.5.mga1 (Core Release) java-1.6.0-sun-devel-1.6.0.25-1.mga1 (Nonfree Release) ---------------------------------------- Done. This just needs a full advisory now so it can be validated.. :)
Whiteboard: mga1-64-OK => mga1-64-OK mga1-32-OK
D Morgan, can you provide an explanation of the "only package the APIs and no webapps anymore" for the advisory? I don't know what this means.
i did a mistake now in the tomcat5-5.5.31-4.5.mga1.src.rpm you have only the libs ( this means the the .jar/pom files needed to build other apps but not tomcat webapp ).
(In reply to comment #66) > i did a mistake now in the tomcat5-5.5.31-4.5.mga1.src.rpm you have only the > libs ( this means the the .jar/pom files needed to build other apps but not > tomcat webapp ). So would this be correct? "The tomcat5 packages now only provide the api needed to build other applications, but not the tomcat webapp itself." Also, the build failed, and you changed the release tag instead of the subrel. http://pkgsubmit.mageia.org/uploads/failure/1/core/updates_testing/20120628073830.dmorgan.valstar.23134/log/tomcat5-5.5.31-5.4.mga1/build.0.20120628073902.log
advisory OK for me. i repushed a new rpm.
Thanks D Morgan. Here's the complete (and hopefully final) advisory. Advisory: ======================== Updated tomcat5 packages fix security vulnerabilities: Multiple cross-site scripting (XSS) vulnerabilities in the HTML Manager Interface in Apache Tomcat 5.5 before 5.5.32, 6.0 before 6.0.30, and 7.0 before 7.0.6 allow remote attackers to inject arbitrary web script or HTML, as demonstrated via the display-name tag (CVE-2011-0013). Multiple flaws were found in the way Tomcat handled HTTP DIGEST authentication. These flaws weakened the Tomcat HTTP DIGEST authentication implementation, subjecting it to some of the weaknesses of HTTP BASIC authentication, for example, allowing remote attackers to perform session replay attacks (CVE-2011-1184, CVE-2011-5062, CVE-2011-5063, CVE-2011-5064). A flaw was found in the Tomcat MemoryUserDatabase. If a runtime exception occurred when creating a new user with a JMX client, that user's password was logged to Tomcat log files. Note: By default, only administrators have access to such log files (CVE-2011-2204). A flaw was found in the way Tomcat handled sendfile request attributes when using the HTTP APR or NIO (Non-Blocking I/O) connector. A malicious web application running on a Tomcat instance could use this flaw to bypass security manager restrictions and gain access to files it would otherwise be unable to access, or possibly terminate the Java Virtual Machine (JVM). The HTTP blocking IO (BIO) connector, which is not vulnerable to this issue, is used by default in Red Hat Enterprise Linux 6 (CVE-2011-2526). native/unix/native/jsvc-unix.c in jsvc in the Daemon component 1.0.3 through 1.0.6 in Apache Commons, as used in Apache Tomcat 5.5.32 through 5.5.33, 6.0.30 through 6.0.32, and 7.0.x before 7.0.20 on Linux, does not drop capabilities, which allows remote attackers to bypass read permissions for files via a request to an application (CVE-2011-2729). A flaw was found in the way the Coyote (org.apache.coyote.ajp.AjpProcessor) and APR (org.apache.coyote.ajp.AjpAprProcessor) Tomcat AJP (Apache JServ Protocol) connectors processed certain POST requests. An attacker could send a specially-crafted request that would cause the connector to treat the message body as a new request. This allows arbitrary AJP messages to be injected, possibly allowing an attacker to bypass a web application's authentication checks and gain access to information they would otherwise be unable to access. The JK (org.apache.jk.server.JkCoyoteHandler) connector is used by default when the APR libraries are not present. The JK connector is not affected by this flaw (CVE-2011-3190). It was discovered that Tomcat computed hash values for form parameters without restricting the ability to trigger hash collisions predictably. A remote attacker could cause a denial of service by sending many crafted parameters (CVE-2011-4858). It was discovered that Tomcat incorrectly handled parameters. A remote attacker could cause a denial of service by sending requests with a large number of parameters and values (CVE-2012-0022). Also, the tomcat5 packages now only provide the api needed to build other applications, but not the tomcat webapp itself. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0013 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1184 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2204 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2526 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2729 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3190 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4858 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0022 https://rhn.redhat.com/errata/RHSA-2011-1780.html http://www.ubuntu.com/usn/usn-1359-1/ http://tomcat.apache.org/security-5.html ======================== Updated packages in core/updates_testing: ======================== tomcat5-servlet-2.4-api-5.5.31-4.5.mga1.noarch.rpm tomcat5-servlet-2.4-api-javadoc-5.5.31-4.5.mga1.noarch.rpm tomcat5-jsp-2.0-api-5.5.31-4.5.mga1.noarch.rpm tomcat5-jsp-2.0-api-javadoc-5.5.31-4.5.mga1.noarch.rpm from tomcat5-5.5.31-4.5.mga1.src.rpm
what an update... urpmi tomcat5 with testing enable adding a reason to already rejected package tomcat5-jasper-5.5.31-4.4.mga1.noarch: unsatisfied tomcat5-servlet-2.4-api[== 0:5.5.31-4.4.mga1] A requested package cannot be installed: tomcat5-jasper-5.5.31-4.4.mga1.noarch (due to unsatisfied tomcat5-servlet-2.4-api[== 0:5.5.31-4.4.mga1]) I guess you rebuild again some package...
(In reply to comment #70) > what an update... > > urpmi tomcat5 with testing enable > > adding a reason to already rejected package > tomcat5-jasper-5.5.31-4.4.mga1.noarch: unsatisfied tomcat5-servlet-2.4-api[== > 0:5.5.31-4.4.mga1] > A requested package cannot be installed: > tomcat5-jasper-5.5.31-4.4.mga1.noarch (due to unsatisfied > tomcat5-servlet-2.4-api[== 0:5.5.31-4.4.mga1]) > > I guess you rebuild again some package... Don't install the 4.4.mga1 packages, they aren't a part of this update. The 4.5.mga1 ones are, and only include api packages. The jasper package is no longer built.
and ? if I install mga1, then make updates, then install tomcat it should work
(In reply to comment #72) > and ? > > if I install mga1, then make updates, then install tomcat it should work If there are orphaned packages still in updates_testing from the previous SRPM, we'll have to have a sysadmin remove them. This issue would not affect users installing the updates if we push the current one to updates. Please just install the updated packages for testing.
should we add obsolete anyway to ease update ?
(In reply to comment #74) > should we add obsolete anyway to ease update ? If the other packages that were removed shouldn't be used, then probably.
I uninstalled all tomcat5 packages, disabled core updates testing, installed all tomcat5 packages then ran mgaapplet ... Sorry, the following packages cannot be selected: - tomcat5-5.5.31-4.4.mga1.noarch (due to conflicts with tomcat5-jasper-5.5.31-4.4.mga1.noarch, due to conflicts with tomcat5-jasper-5.5.31-4.4.mga1.noarch) - tomcat5-admin-webapps-5.5.31-4.4.mga1.noarch (due to unsatisfied tomcat5[*][== 0:5.5.31-4.4.mga1]) - tomcat5-common-lib-5.5.31-4.4.mga1.noarch (due to conflicts with tomcat5-jasper-5.5.31-4.4.mga1.noarch) - tomcat5-jasper-5.5.31-4.4.mga1.noarch (due to unsatisfied tomcat5-servlet-2.4-api[== 0:5.5.31-4.4.mga1]) - tomcat5-server-lib-5.5.31-4.4.mga1.noarch (due to unsatisfied tomcat5-jasper[== 0:5.5.31-4.4.mga1]) - tomcat5-webapps-5.5.31-4.4.mga1.noarch
(In reply to comment #76) > I uninstalled all tomcat5 packages, disabled core updates testing, > installed all tomcat5 packages then ran mgaapplet ... > > Sorry, the following packages cannot be selected: > > - tomcat5-5.5.31-4.4.mga1.noarch (due to conflicts with > tomcat5-jasper-5.5.31-4.4.mga1.noarch, due to conflicts with > tomcat5-jasper-5.5.31-4.4.mga1.noarch) > - tomcat5-admin-webapps-5.5.31-4.4.mga1.noarch (due to unsatisfied > tomcat5[*][== 0:5.5.31-4.4.mga1]) > - tomcat5-common-lib-5.5.31-4.4.mga1.noarch (due to conflicts with > tomcat5-jasper-5.5.31-4.4.mga1.noarch) > - tomcat5-jasper-5.5.31-4.4.mga1.noarch (due to unsatisfied > tomcat5-servlet-2.4-api[== 0:5.5.31-4.4.mga1]) > - tomcat5-server-lib-5.5.31-4.4.mga1.noarch (due to unsatisfied > tomcat5-jasper[== 0:5.5.31-4.4.mga1]) > - tomcat5-webapps-5.5.31-4.4.mga1.noarch Those 4.4 packages are from a previous build. Trying doing it with the applet but deselect those ones. The only ones that should be selected are: tomcat5-servlet-2.4-api-5.5.31-4.5.mga1.noarch.rpm tomcat5-servlet-2.4-api-javadoc-5.5.31-4.5.mga1.noarch.rpm tomcat5-jsp-2.0-api-5.5.31-4.5.mga1.noarch.rpm tomcat5-jsp-2.0-api-javadoc-5.5.31-4.5.mga1.noarch.rpm
(In reply to comment #77) > Those 4.4 packages are from a previous build. Trying doing it with the applet > but deselect those ones. The only ones that should be selected are: > tomcat5-servlet-2.4-api-5.5.31-4.5.mga1.noarch.rpm > tomcat5-servlet-2.4-api-javadoc-5.5.31-4.5.mga1.noarch.rpm > tomcat5-jsp-2.0-api-5.5.31-4.5.mga1.noarch.rpm > tomcat5-jsp-2.0-api-javadoc-5.5.31-4.5.mga1.noarch.rpm Then they should be removed from updates_testing. Or not?
CC: (none) => sander.lepik
(In reply to comment #78) > Then they should be removed from updates_testing. Or not? Yes, they should.
I'll ask on the sysadmin mailing list for someone to remove the following rpm packages from Core Updates Testing. tomcat5 tomcat5-admin-webapps tomcat5-common-lib tomcat5-jasper tomcat5-jasper-eclipse tomcat5-jasper-javadoc tomcat5-server-lib tomcat5-webapps Until they've been removed, it's problematic confirming that the update will install cleanly using mgaapplet.
(In reply to comment #80) > I'll ask on the sysadmin mailing list for someone to remove the following > rpm packages from Core Updates Testing. > tomcat5 > tomcat5-admin-webapps > tomcat5-common-lib > tomcat5-jasper > tomcat5-jasper-eclipse > tomcat5-jasper-javadoc > tomcat5-server-lib > tomcat5-webapps > > Until they've been removed, it's problematic confirming that the update > will install cleanly using mgaapplet. Removed from primary mirror.
CC: (none) => tmb
Thanks Thomas. As I feared, with those packages gone from the mirror I'm using, I still get ... The following packages have to be removed for others to be upgraded: tomcat5-5.5.31-3.mga1.noarch (due to unsatisfied tomcat5-common-lib == 0:5.5.31-3.mga1, due to unsatisfied tomcat5-common-lib == 0:5.5.31-3.mga1, due to unsatisfied tomcat5-server-lib == 0:5.5.31-3.mga1, due to unsatisfied tomcat5-server-lib == 0:5.5.31-3.mga1) tomcat5-admin-webapps-5.5.31-3.mga1.noarch (due to unsatisfied tomcat5 == 0:5.5.31-3.mga1) tomcat5-common-lib-5.5.31-3.mga1.noarch (due to unsatisfied tomcat5-jsp-2.0-api == 0:5.5.31-3.mga1, due to unsatisfied tomcat5-jsp-2.0-api == 0:5.5.31-3.mga1) tomcat5-jasper-5.5.31-3.mga1.noarch (due to unsatisfied tomcat5-servlet-2.4-api == 0:5.5.31-3.mga1) tomcat5-server-lib-5.5.31-3.mga1.noarch (due to unsatisfied tomcat5-jasper == 0:5.5.31-3.mga1, due to unsatisfied tomcat5-jasper == 0:5.5.31-3.mga1) tomcat5-webapps-5.5.31-3.mga1.noarch (due to unsatisfied tomcat5 == 0:5.5.31-3.mga1)
i will add obsolete to avoid this to happen
I don't think this has been rebuilt yet. There are no tomcat5 packages in testing. Assigning dmorgan again, could you have a look at this please when you have some time. Please reassign QA when you've had a chance. Thanks!
Status: NEW => ASSIGNEDAssignee: qa-bugs => dmorganecWhiteboard: mga1-64-OK mga1-32-OK => (none)
This message is a reminder that Mageia 1 is nearing its end of life. In approximately 25 days from now, Mageia will stop maintaining and issuing updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '1'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 1's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 1 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- Mageia Bugsquad
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: ASSIGNED => RESOLVEDResolution: (none) => WONTFIX