stoty commented on PR #2277: URL: https://github.com/apache/zookeeper/pull/2277#issuecomment-3046141742
> I'm sorry @stoty , but this is the 5th patch that you create on this topic and it's getting impossible for me to follow. I think it would be beneficial to discuss and address the issues separately. I don't really like "clean up" style patches, especially when there're significant changes in the logic. This is not cleaning up. > > So, I can identify the following issues: > > * setting OCSP/CRL Java properties explicitly to "true" on the client side while we want to follow system default. I don't want to change this behaviour on the server side at all. This is strictly a client side improvement. Mostly. We can discuss the implementation details in the separate patch I'm going to open. As for "this is strictly a client side improvement" : This is only really a problem on the client side. As everything is backwards compatible, I would prefer to also make these changes on the server side, as the TLS code is structured so that it's harder to make client side only changes than to make the same changes on the server side. > * setting OCSP stapling in OpenSSL provider only. There should be a way to check availability in Netty for this rather than relying on enum values. How about using `OpenSsl.isAvailable()` and `OpenSsl.isOcspSupported()` flags together? Yes, that's ZOOKEEPER-4940. However, OpenSsl.is* is NOT helpful here. We don't care whether OpenSSL is loaded or not, or what it supports. None of that matters if the SSL provider is set to JRE, and tcnative is never used. Please see the reopened #2270 for ZOOKEEPER-4940 for the standalone patch. > * using built-in hostname verification even if Fips style is disabled and we don't have trustStore defined Check > > Is the above accurate? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@zookeeper.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
