RELEASED: July 27, 2022
- Git client plugin versions prior to 3.11.1 are vulnerable to man-in-the-middle attacks (BEE-21945)
Git client plugin versions prior to version 3.11.1 are vulnerable to man-in-the-middle attacks. Additionally, because the CloudBees Git Validated Merge plugin uses the Git client plugin to provide an SSH connection, it is also vulnerable.
This issue has been resolved. The Git client plugin now lets you select from the following options to verify the SSH keys that are presented by the Git repository host servers:
Accept first connection strategy (default) - Automatically adds keys to the
known_hostsfile for hosts that have not been seen before. This option prevents connections to previously seen hosts, if the keys have been modified.
Known hosts file - This option verifies that all host keys use the
Manually provided keys - This option verifies that all host keys use a set of manually configured keys.
No verification - Does not verify host keys. This option is insecure, it is not recommended.
To configure the host key verification strategy, select.
- OpenSSH releases before OpenSSH 7.6 (released Oct 2017) do not support the
sshcommand line argument used to accept the first connection (BEE-22139)
Red Hat Enterprise Linux 7, CentOS 7, AWS Linux 2, and Debian 9 all deliver OpenSSH releases older than OpenSSH 7.6. The Git Host Key Verification Configuration for those systems cannot use the Accept first connection strategy with the command line
Users of those operating systems have the following options:
Use the Manually provided Verification Strategy and provide host keys for their git hosts.
Use the Known hosts file Verification Strategy and provide a
known_hostsfile on the agents with values for the required hosts.
Enable JGit and use JGit instead of command line
giton agents and controllers that have older OpenSSH versions.
Switch the repository URLs in the job definitions from SSH protocol to HTTPS protocol and provide a username/password credential for the clone instead of a private key credential.
Use the Non verifying host key verification strategy (not recommended).
- Jenkins logs are not appended to the service log file in an RPM installation that uses Java 8 (BEE-20636)
If you use an RPM to upgrade the product while using Java 8, the Jenkins logs are no longer appended to the following configured service log by default:
You should migrate to Java 11 to resolve this issue. For more information, refer to Migrating to Java 11.
- Duplicate Pipeline Template Catalogs in the Configuration as Code (CasC) for Controllers
jenkins.yamlfile on each instance restart (BEE-12722)
If a Pipeline Template Catalog is configured in the CasC
jenkins.yamlfile and the
idproperty is not defined, the catalog is duplicated on each instance restart and in the exported CasC configuration.
- Migration to Java 11 will soon be required for new releases (BEE-42)
The Jenkins community will support the Java 11-specific features soon (Java 11 byte code) and then you cannot use a Java 8 runtime environment. Because CloudBees Jenkins Platform is based on the Jenkins LTS, future releases of CloudBees Jenkins Platform will have the same requirement.
CloudBees strongly recommends that you upgrade your CloudBees Jenkins Platform environment to run Java 11 as soon as possible. Some of the Java 11 updates may require action on your part, and there may be a specific order in which you must upgrade components in your environment. For more information, refer to Migrating to Java 11.
- When you upgrade to Java 11, you must update your Java garbage collection arguments (BEE-16018)
Garbage collection has been updated in Java 11. Many of the previously recommended arguments are no longer supported. When you upgrade your JDK to Java 11, you must also update your garbage collection configuration. Using unsupported Java arguments will result in startup failure.
For more information, refer to Adding Java arguments to the Jenkins service configuration file.
- Jenkins upgrade notes