On Wed, 20 Apr 2022 10:28:39 GMT, Daniel Jeliński <[email protected]> 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
