On Wed, 20 Apr 2022 10:28:39 GMT, Daniel Jeliński <djelin...@openjdk.org> wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java >> line 94: >> >>> 92: AlgorithmConstraints userSpecifiedConstraints, >>> 93: boolean withDefaultCertPathConstraints) { >>> 94: if (nullIfDefault(userSpecifiedConstraints) == null) { >> >> Do you wan to check DEFAULT_SSL_ONLY in the nullIfDefault() implementation? >> The logic of the block is a little bit hard to understand to me. > > No I don't; it's for the same reason why I'm using `==` and not `equals`: > `DEFAULT` is the only `SSLAlgorithmConstraints` instance that is ever used as > `userSpecifiedConstraints` here. > > `DEFAULT` is used because [SSLConfiguration sets > userSpecifiedAlgorithmConstraints to > SSLAlgorithmConstraints.DEFAULT](https://github.com/openjdk/jdk/blob/6d8d156c97b90a9ab4776c6b42563a962d959741/src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java#L129). > This feels wrong; the name suggests that the constraints should be specified > by user, and should be null if the user doesn't touch them. > `userSpecifiedAlgorithmConstraints` are accessible by > `getSSLParameters().getAlgorithmConstraints()` on SSLEngineImpl and > SSLSocketImpl. Returning `DEFAULT` here also feels wrong; as a user I would > be concerned that setting my own algorithm constraints would replace the > default ones. It doesn't, but that is not immediately apparent. > > We could initialize `userSpecifiedAlgorithmConstraints` to null, and back out > all the other changes from this PR. The only reason why I didn't do that was > because it would change the observable behavior > (`getSSLParameters().getAlgorithmConstraints()` would return `null`). If you > think we can live with that, I'll be happy to do that change. It is not interested to me to use 'null' constraints in ssl configure. I have no more comments. Thank you for the update! ------------- PR: https://git.openjdk.java.net/jdk/pull/8199