RFR: 8280494: (D)TLS signature schemes [v4]

Bernd duke at openjdk.java.net
Sun Jan 30 03:11:12 UTC 2022


On Sat, 29 Jan 2022 05:31:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 763:
>> 
>>> 761: 
>>> 762:         String[] tempSchemes = signatureSchemes.clone();
>>> 763:         for (String scheme : tempSchemes) {
>> 
>> In addition to this loop we could also parse/decompose the strings. This would do the work only once (if the parameter is reused)
>
> If we want to reuse the result, we may have to cache something.  It is not good to me.  The parsing of the signature scheme names actually depends on the provider.  So at this point, in the Java SE API specification, it is not easy to know how to parse the strings to me.

Yes you are right, it would require a setter where the provider can register the resolved array into the parameter instance (if we need to support multiple providers). But it would be a good optimization assuming clients keep the parameters around in a frequent Connection scenario.

>> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 262:
>> 
>>> 260:         }   // otherwise, use the default values
>>> 261: 
>>> 262:         String[] ss = params.getSignatureSchemes();
>> 
>> If we don’t use the cloning getter here (and use the pre-parsed list) it would be more efficient.
>
> Yes.  Array copy is a concern of mine, too.  Hopefully, the frozen array feature could help address the array copy issues in the future.

Hmm.. I guess the different packages make it really hard to have an internal optimized getter. What about a single concatenated string, it would be immutable „sig1,sig2“..

>> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 439:
>> 
>>> 437:                     (config.signatureSchemes == null ||
>>> 438:                         config.signatureSchemes.length == 0 ||
>>> 439:                         Arrays.asList(config.signatureSchemes)
>> 
>> Is that a allocation per handshake*availablesize?
>
> Yes, it does.  Do you like to use a for-loop, without new object allocation?

Yes, static helper

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252



More information about the security-dev mailing list