[Backport 3.11.x][JENKINS-69149] Set 'Known hosts file' strategy as default

[Pldi23]

Target branch should be changed to equal to 3.11.1.

Backport to 3.11.1 for #882
JENKINS-69149

[MarkEWaite]

Thanks!

[MarkEWaite]

@Pldi23 I've created the https://github.com/jenkinsci/git-client-plugin/tree/3.11.x branch so that you can change the target of this pull request to that branch.

[Pldi23]

Thanks Mark, destination branch changed to 3.11.x

[joshsleeper]

fwiw it would've been nice for this to be categorized as a breaking change as well, since it totally had potential to break existing usage relying on the previous behavior

[MarkEWaite]

fwiw it would've been nice for this to be categorized as a breaking change as well, since it totally had potential to break existing usage relying on the previous behavior

I've consistently seen that any change to the git client plugin will be perceived as a breaking change by some users. That's one of the reasons that a future version of the git client plugin will switch to versions numbers generated by continuous delivery. Users will need to read the changelog to decide if a release is a breaking change.

[joshsleeper]

I hear that, truly I do, and I appreciate all the work you all do maintaining this.

It's just that in this case it seems like a default auth check behavior was changed, which in most contexts I would consider a breaking change unless it happened to make things less strict by default.

however, since this effectively changed from "trust on first connection" to "only trust known connections", I'd def lean towards calling it a breaking change for the decent amount of folks probably relying on that first connection to just work.

[clockrun]

• 1 for trust on first connection.
  Otherwise how can I setup initial entry in known_hosts file

[MarkEWaite]

@clockrun You're welcome to set it to "first connection". It is configured from the "Configure global security" page. We had many complaints from OpenSSH 7.4 users (CentOS 7, AWS Linux 2, etc.) that prompted the change from the "first connection" as default to "known hosts file". We don't plan to change it back.

With static agents, there is not much difference between "first connection" and "known hosts file", since the known hosts file likely exists in both cases.

The git plugin documentation includes an example that configures for a manually specified known hosts file. You can do the same or you can configure it from the "Configure global security" page to specify the contents of the known hosts file.

[usmonster]

Completely agree with @joshsleeper that this is indeed a breaking change, as it broke CI for my entire engineering team (we use ephemeral Jenkins agents) before we identified the issue and applied the workaround. This situation should not be possible for a patch update.

Users will need to read the changelog to decide if a release is a breaking change.

This isn't scalable, especially for contexts where several "safe" updates are automated by bots. (Also, a breaking change is usually not ambiguous–for example, any change in default behavior can be seen as breaking or potentially breaking.)

What could be more reasonable is to enforce using conventional commits in this repo to mark each code change appropriately at development time, and implement CD that will take these into account in its versioning. This will make it easier for Jenkins users, especially those using lots of plugins, to know when they should be able to safely upgrade or when they should expect breakage and read the changelog.

Please, please consider something like this to maintain semantic versioning over the {increment}.{hash} versioning system described in the page you linked to! Thanks! 🙏