RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v2]
Matthew Donovan
mdonovan at openjdk.org
Tue Oct 28 17:43:16 UTC 2025
On Tue, 28 Oct 2025 13:58:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:
>> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>>
>> - fixed indents and copyright year
>> - Merge branch 'master' into update-md5-certs
>> - 8353738: Update TLS unit tests to not use certificates with MD5 signatures
>
> test/jdk/javax/management/security/keystoreAgent line 1:
>
>> 1: 0�
>
> Why do we need this and other binary key stores if we generate certificates on the fly?
This is related to your question about SecurityTest.java.
SecurityTest.java has about 24 different @run instructions with different flags for each. Setting up keys and certificates programmatically looked like it would make the code more complicated and keeping the binary files seemed like the lesser of two evils.
> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 42:
>
>> 40:
>> 41: /*
>> 42: * @test id=tls13
>
> What's the reason for having 2 separate `@test id=tls12` and `@test id=tls13` JTREG instructions blocks?
I think it helps with organization and troubleshooting tests. Without it, you have to read fairly dense logs to see which @run command failed. With separate @test blocks, it's more obvious.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470468093
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470461925
More information about the net-dev
mailing list