Comments

62 Comments

We are going to do a FreeIPA 4.8 release tomorrow that will include the fixes for AJP protection (and will migrate old configuration to a new one too).

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.

It's the secret. Alexander is working on a PR to address the issue, https://github.com/freeipa/freeipa/pull/4337

I'm afraid I don't, I'm just the test monkey :) ab might.

@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?

karma

This breaks the openQA FreeIPA tests - see links on Automated Tests tab. Logs available in 'Logs & Assets' tab of the failed tests. Didn't look into the cause myself yet, but it definitely broke something. @ab

karma

Same as F31 update, this breaks the openQA FreeIPA tests - see links on Automated Tests tab. Logs available in 'Logs & Assets' tab of the failed tests. Didn't look into the cause myself yet, but it definitely broke something. @ab

karma

This breaks the openQA FreeIPA tests - see links on Automated Tests tab. Logs available in 'Logs & Assets' tab of the failed tests. Didn't look into the cause myself yet, but it definitely broke something. @ab

karma

+1

karma

Works

karma

works as usual

karma

works great

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.

karma

works

karma

There were some inconsistencies:

 Problem 1: conflicting requests
  - nothing provides tomcat-lib = 1:8.0.53-1.fc27 needed by tomcat-1:8.0.53-1.fc27.noarch
 Problem 2: package tomcat-webapps-1:8.0.53-1.fc27.noarch requires tomcat = 1:8.0.53-1.fc27, but none of the providers can be installed
  - conflicting requests
  - nothing provides tomcat-lib = 1:8.0.53-1.fc27 needed by tomcat-1:8.0.53-1.fc27.noarch
 Problem 3: package tomcat-jsvc-1:8.0.53-1.fc27.noarch requires tomcat = 1:8.0.53-1.fc27, but none of the providers can be installed
  - conflicting requests
  - nothing provides tomcat-lib = 1:8.0.53-1.fc27 needed by tomcat-1:8.0.53-1.fc27.noarch
 Problem 4: package tomcat-docs-webapp-1:8.0.53-1.fc27.noarch requires tomcat = 1:8.0.53-1.fc27, but none of the providers can be installed
  - conflicting requests
  - nothing provides tomcat-lib = 1:8.0.53-1.fc27 needed by tomcat-1:8.0.53-1.fc27.noarch
 Problem 5: package tomcat-admin-webapps-1:8.0.53-1.fc27.noarch requires tomcat = 1:8.0.53-1.fc27, but none of the providers can be installed
  - conflicting requests
  - nothing provides tomcat-lib = 1:8.0.53-1.fc27 needed by tomcat-1:8.0.53-1.fc27.noarch
karma

works for me

karma

works for me

karma

+1

karma

works