Tomcat 9.0.115, 10.1.52, and 11.0.18 include a breaking change [1] to
how ciphers are configured when using HTTPS. Previously, a single
setting was used but this has now been split in two; the existing
ciphers setting for TLSv1.2 ciphers and a new ciperSuites setting for
TLSv1.3. As part of this split, the behavior of the ciphers setting
has been changed such that any TLSv1.3 ciphers are ignored and a
warning is logged.
This change in Tomcat is problematic without also making some changes
in Boot. If we had done nothing, a user that had configured only
TLSv1.3 cipers would have them all ignored, leaving their SSL
connection unexpectedly using all of the default ciphers which may be
less secure.
This commit adapts to the breaking change in Tomcat by taking the
user's list of ciphers and splitting into into TLSv1.2 and TLSv1.3
ciphers before passing them into Tomcat's two settings (ciphers and
cipherSuites respectively). This is done defensively for backwards
compatibility. If the methods to identify and configure the TLSv1.3
ciphers are not present, we assume that we're running with an earlier
version of Tomcat and fall back to passing them all into the ciphers
setting as we did previously.
Closes gh-49143
[1] 9abf6bddb2
Tomcat 9.0.115, 10.1.52, and 11.0.18 include a breaking change [1] to
how ciphers are configured when using HTTPS. Previously, a single
setting was used but this has now been split in two; the existing
ciphers setting for TLSv1.2 ciphers and a new ciperSuites setting for
TLSv1.3. As part of this split, the behavior of the ciphers setting
has been changed such that any TLSv1.3 ciphers are ignored and a
warning is logged.
This change in Tomcat is problematic without also making some changes
in Boot. If we had done nothing, a user that had configured only
TLSv1.3 cipers would have them all ignored, leaving their SSL
connection unexpectedly using all of the default ciphers which may be
less secure.
This commit adapts to the breaking change in Tomcat by taking the
user's list of ciphers and splitting into into TLSv1.2 and TLSv1.3
ciphers before passing them into Tomcat's two settings (ciphers and
cipherSuites respectively). This is done defensively for backwards
compatibility. If the methods to identify and configure the TLSv1.3
ciphers are not present, we assume that we're running with an earlier
version of Tomcat and fall back to passing them all into the ciphers
setting as we did previously.
Closes gh-49108
[1] 9abf6bddb2
Change `spring-boot-tomcat-runtime` and `spring-boot-jetty-runtime`
into starter POMs and reduce the number of dependencies needed for
`spring-boot-tomcat` and `spring-boot-jetty`.
The runtime starters provide only the jars required to run the
embedded server along with the module jar itself (excluding transitive
dependencies) and `spring-boot-webserver` (excluding transitive
dependencies).
The build setup required for an executable jar is slightly different
between Maven and Gradle. For Maven, the regular module is put in the
`provided` scope. For Gradle, the regular module remains in main
configuration and the runtime jar is put in the `providedRuntime`
configuration. The reference documentation has been updated to
show how to configure things if starters are being used.
Manual testing has been performed to ensure that wars build with Maven
and Gradle work with both Tomcat and Jetty in both deployed and
`java -jar` modes.
Closes gh-48175
Refactor `PropertyMapper` so that it no longer calls adapter or
predicate methods by default when the source value is `null`. This
effectively makes all default calls the same as using
`alwaysWhenNotNull` in the previous generation of the code.
For the limited times when you do need to deal with `null` values, the
new `always()` method can be used.
For example,
map.from(source::method).to(destination::method);
Will not call `destination.method(...)` if `source.method()` returns
`null`.
Where as:
map.from(source::method).always().to(destination::method);
Will call `destination.method(null)` if `source.method()` returns
`null`.
This update provides clearer semantics for the API and allows for better
JSpecify nullability annotations. It has also simplified much of our
existing property mapper code.
Closes gh-47024
Co-authored-by: Moritz Halbritter <moritz.halbritter@broadcom.com>
The enum itself is not specifically tied to auto-configuration so
spring-boot is a better place for it. The related condition,
`@ConditionalOnThreading`, remains in spring-boot-autoconfigure. This
aligns things with the similar `CloudPlatform` and
`@ConditionalOnCloudPlatform`.
Closes gh-46406
Andy Wilkinson
jdsalasca
Phillip Webb
Moritz Halbritter
Stéphane Nicoll
Kevin Zittritsch