Comments

20 Comments

Given the issues that have shown up after this attempted upgrade we decided to open a change proposal instead to alert everyone that it's being planned. The proposal is at https://fedoraproject.org/wiki/Changes/Tomcat10ChangeProposal

This update has been unpushed.

This update has been unpushed.

This issue is because of javaee -> jakartaee migration that isn't done in the app.

May 31 19:53:46 example.redhat.com server[6759]: Caused by: java.lang.ClassNotFoundException: javax.servlet.http.HttpServletResponse

The failure in the scanning is due to necessary catalina.properties changes in the PKI configurations :( The following will clear the scanner failures (but there should probably be more jars added to match the current version upstream):

--- conf/catalina.properties.orig   2024-05-31 19:45:43.846548383 -0400
+++ conf/catalina.properties    2024-05-31 19:46:22.194548383 -0400
@@ -139,7 +139,7 @@ junit.jar,junit-*.jar,hamcrest-*.jar,eas
 objenesis-*.jar,ant-launcher.jar,\
 cobertura-*.jar,asm-*.jar,dom4j-*.jar,icu4j-*.jar,jaxen-*.jar,jdom-*.jar,\
 jetty-*.jar,oro-*.jar,servlet-api-*.jar,tagsoup-*.jar,xmlParserAPIs-*.jar,\
-xom-*.jar
+xom-*.jar,bcel*.jar,commons-compress*.jar,jakartaee-migration-*.jar

 # Default list of JAR files that should be scanned that overrides the default
 # jarsToSkip list above. This is typically used to include a specific JAR that

I'll reach out to the FreeIPA folks and get this sorted.

Yeah, apparently the tomcat-jakartaee-migration tool has some issues to sort out, and the tomcatjss package needs fixing to work with the new tomcat version. This build was created so the PKI folks could start building FreeIPA against the new tomcat version. We probably should have waited a bit before doing the updates...

We should only be updating tomcat-native to version 2.0.x in the latest (rawhide) branch of Fedora as it will break some instances. Tomcat Native 2.0.x does not support the APR connectors.

This update has been unpushed.

This update has been unpushed.

I think it's best to rollback those default changes for f30-f32 (and fix this like I did for RHEL) so we don't break current user environments. The work done in the freeipa project to use the secret is still valid, but after I introduce a new build it won't be broken by default.

@adamwill @abbra the breakage occurred due to changes in the defaults on the AJP Connector to mitigate CVE-2020-1938. There are two changes that likely caused issue: the default bind address for the connector changed from all interfaces to localhost and the connector will no longer start unless you define a secret. We can proceed two different ways. You can update the FreeIPA configuration to address those (add 'address' and 'secretRequired=false' to your Connector config), or I can create a patch to undo those changes (which is what I did for RHEL tomcat). The problem with the second approach is that I don't know of any mechanism to tell users that they need to review their configurations, so they likely won't do anything and remain vulnerable to exploitation. Got any tips on that?

LGTM

BZ#1374210 CVE-2016-3110 mod_cluster: remotely Segfault Apache http server [fedora-all]

LGTM

BZ#1374210 CVE-2016-3110 mod_cluster: remotely Segfault Apache http server [fedora-all]

LGTM

BZ#1374210 CVE-2016-3110 mod_cluster: remotely Segfault Apache http server [fedora-all]
BZ#1708248 Segfaults in Apache after updating packages (using mod_cluster and mod_ssl)

Are you sure this isn't an environmental issue? The changes committed to rebase were minimal and should not have caused this problem. Additionally, looking at the build information in koji shows that the tomcat-lib package does in fact provide "tomcat-lib = 1:8.0.53-1.fc27". I'll setup a VM to test as soon as I can, but I don't see any cause for this at first glance.

This update has been unpushed.

wfm too :)

BZ#1375581 CVE-2016-5388 Tomcat: CGI sets environmental variable based on user supplied Proxy request header [fedora-all]
BZ#1383216 CVE-2016-6325 tomcat: tomcat writable config files allow privilege escalation [fedora-all]
BZ#1383210 CVE-2016-5425 tomcat: Local privilege escalation via systemd-tmpfiles service [fedora-all]
BZ#1370262 catalina.out is no longer in use in the main package, but still gets rotated
BZ#1390532 CVE-2016-0762 CVE-2016-5018 CVE-2016-6794 CVE-2016-6796 CVE-2016-6797 tomcat: various flaws [fedora-all]

I was under the impression that adding a new build would remove the old one, but maybe that isn't the case. I do see that this update is pending the push to testing, so maybe when that happens the old build will be removed. I'm going to wait and see what happens when this update is pushed to testing. If it doesn't resolve it, I'll try untagging the 8.0.37-3 build.

Thanks for pinning that down @abbra; I'll rebase to 8.0.38 asap.

I tested mod_cluster, mod_cluster-java, mod_cluster-java-tomcat8 with tomcat8 (1:8.0.36-2.fc25) and it works fine.

BZ#1368613 mod_cluster: Update to 1.3.3.Final