SECURITY-1468's solution impacts ATH builds

[NotMyFault]

After investigating into the failure of #876, ATH is impacted by the security fix in the git-client-plugin too, jenkinsci/git-client-plugin#875, because ATH runs on CentOS 7 and doesn't know how to deal with "accept new" as strategy.

Later reading over JENKINS-69149, am I correct assuming that jenkinsci/git-client-plugin#882 restores the functionality of ATH, once merged and released?

[dwnusbaum]

am I correct assuming that jenkinsci/git-client-plugin#882 restores the functionality of ATH, once merged and released?

Unless Main.isUnitTest is set when running the ATH (I don't think it is), then if the ATH is built on ephemeral agents with a blank known_hosts file, or if it connects to dynamically created Git servers where the host keys change every time the test runs, then no, it will still need to be adapted.

From a quick look, I think that GitPluginTest and similar tests will need to either populate known_hosts on the agent with the host key information from the container running the Git server, or they will need to configure the controller to use the "Manually Provided Keys" host key verifications strategy and provide the keys for the Git server there, or maybe configure the "No verification" host key verification strategy if we know the ATH only connects to local Git servers and we do not care about MitM attacks.

CC @Pldi23 in case my comment is not quite right

[timja]

Or we can move to recent Ubuntu with accept-new

[NotMyFault]

Or we can move to recent Ubuntu with accept-new

I started with that in #878 earlier, needs some fixup in terms of Java directories to get it to work 👀

[dduportal]

Dropping a note: we discussed this issue in today's infra meeting because the weekly release 2.363 was also bitten by this behavior on ci.jenkins.io.

Expect a fix in ci.jenkins.io wednesday 10th of August to apply the config as code change.

[timja]

It’s an ATH framework change though, we’re trying to upgrade to a more maintained OS but tests are failing on it :(

[dduportal]

It’s an ATH framework change though, we’re trying to upgrade to a more maintained OS but tests are failing on it :(

Depends if the git-client is configured to use JGit or native git on ci.jenkins.io if I'm not mistaken.
At least the infra team can set up the expected host keys from github.com for cases with JGit.

If the ATH uses the native git client, then adding an instruction ssh-keyscan -H github.com >> /home/jenkins/.ssh/known_hosts should also help

[dduportal]

Manual configuration to validate:

• Stopped puppet agent on ci.jenkins.io VM to avoid manual configuration change to be lost
• Set up ci.jenkins.io (security settings), section "Git Host Key Verification Configuration" , to manually provided key and added the github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl
• Triggered a new build: https://ci.jenkins.io/job/Core/job/acceptance-test-harness/job/PR-880/2/ (Bump jenkins from 1.82 to 1.85 #880 superseded Bump jenkins from 1.82 to 1.83 #876)

[timja]

it's not checking out via ci.jenkins.io, it's checking out in the tests.

Those changes won't impact it

[Pldi23]

I created a #886 with proposal to use 'No verification' strategy for ATH, because git-client 3.11.2 uses 'Known hosts file' as default strategy instead of 'Accept first connection' used in git-client 3.11.1, so tests will continue to fail even when we switch recent Ubuntu. I only worries if we are sure that ATH only connects to local git servers and we could not worry about MitM attacks?

[timja]

We ignored it the last 10 years or whatever I don't see it being a concern in this repository