On Mon, 29 Jun 2026 18:49:54 GMT, Andreas Chmielewski
<[email protected]> wrote:
>> test/jdk/javax/net/ssl/ciphersuites/BulkCipherDisabledAlgorithms.java line
>> 77:
>>
>>> 75: private static List<String[]> buildTests() throws
>>> NoSuchAlgorithmException {
>>> 76: List<String[]> tests = new ArrayList<>();
>>> 77: CipherSuite[] suites = getCipherSuites(false);
>>
>> We are getting cipher suites here with the default
>> `jdk.tls.disabledAlgorithms` security property set. We need to clear it
>> (first line in `main`) to cover all possible cipher suites.
>
> That’s a good point, thanks!
>
> My test consists of two sub-tests (testCipherSuiteVisibility and
> testHandshake). After clearing jdk.tls.disabledAlgorithms (to cover all
> possible cipher suites), iterating over getSupportedCipherSuites() works fine
> for testCipherSuiteVisibility, since the goal is to verify which suites are
> filtered out by the security property.
>
> However, for testHandshake this approach leads to failures for some supported
> cipher suites that are not actually handshakeable (e.g., Unsupported
> signature algorithm: DSA for DHE_DSS suites, or anonymous cipher suites which
> are not enabled by default). These failures are unrelated to the behavior
> under test.
>
> Therefore, for the handshake test it seems necessary to restrict the set to
> suites that are both enabled by default and handshakeable (e.g., using
> getEnabledCipherSuites() a), while still using the full supported set for the
> visibility checks.
>
> @artur-oracle What do you think?
Of course, for the handshake we can use the default
`jdk.tls.disabledAlgorithms` security property. We juts want to make sure we
decompose bulk ciphers for all cipher suites.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31633#discussion_r3494170960
